-
Notifications
You must be signed in to change notification settings - Fork 0
Home
DCAP, Distributed Cloud Application Platform, is a software development framework and a runtime engine for building and running distributed applications (e.g. mobile applications) and distributed services (e.g. middleware services).
The goal of DCAP is to 1) reduce the complexity of coding distributed system and 2) improve the quality of end product by providing proven pre-built plugins for various kinds of distributed tasks so that developers no longer need to write code to tackle these distributed tasks. It is especially useful for application developers who are working on distributed systems but are not savvy in dealing with distributed tasks.
- Easy to develop and test sophisticated distributed applications with DMs
- 80% of applications only need existing DM’s, or easy combinations of existing DM’s.
- 15% of applications only need minor modifications of existing DM’s
- 5% of applications need completely new DM’s
- Easy to build new DMs via DM composition
- Easy to manage in production
- Easy to understand and combine features of Sapphire, Diamond, Tapir and Agate.
- DCAP footprint should be small. Small footprint will allow DCAP to penetrate many edge use cases.
- Can run on any cloud server.
- Can run on any android device
- Can run on any iPhone
- Can run on edge devices
- Faster than today’s typical hand-coded applications (e.g. clients written in java or swift that use REST over HTTP to servers written in Go, Java or C++ and use existing backend services like RDB, kafka etc). Within 20% of hand-coded, hand optimized applications that use e.g. protobufs. Portable and language agnostic.
Support multiple languages. Developers can choose their preferred language.
- Java
- Python
- Go
- C/C++
Ultimately, Huawei HQ team will decide whether or not to open source DCAP.
- Welcome outside contributors
- Find a good home. Propose CNCF as that home.
- Mitigate security concerns around Huawei across the globe.
- De facto standard for distributed systems development.
- Deliver a DCAP Java framework with a collection of pre-built DMs, including, but not limited to, the 26 DMs described in Sapphire paper. This DCAP Java framework will provide sufficient capabilities for users to develop complex distributed Java applications or services. By using DCAP, users will experience benefits like easy to code, less error prone, more productive.
- Provide basic integration with Kubernetes. User will be able to run DCAP applications in Kubernetes. DCAP will provide standard helm charts to start DCAP components like OMS and Kernel Servers. Deep integration with Kubernetes, e.g. integrated scale in/out between DCAP object and Kubernetes Pod, is a stretch goal.
- Stretch goal: Support other programming languages in DCAP
- Deliver distributed data management
- Deliver distributed transaction management
- Deliver phase I deliverables by 09/30
- Get positive feedback from two customers who have ported their applications to DCAP or evaluated DCAP by 11/30
Note: HQ team should help US team to find customers for DCAP evaluation. US team will support HQ team in customer engagement by demonstrating the power of DCAP.
- DCAP is widely used inside Huawei or widely adopted in open source world.
-
Transforming Monomer Applications into Distributed Applications. In the current CSE, including Springcloud and dubbo, we can create distributed services with a small amount of code change. What is special on DCAP? Does it offer essential difference in registration discovery mechanism? scalability? performance?
- Imagine we plan to create a mobile application. The developer needs to create mobile app frontend on Andoid or IOS, and then create a backend service with CSE. Often mobile app developer and backend service developer are two different groups of developers because their skill sets are different. DCAP wants to make it easier. Developers create non-distributed applications and DCAP helps them to convert the application to distributed applications. Moreover, today, to write an application, developers have to use a lot of open source components, e.g. kafka for messaging, etcd for synchronization, redis for caching, cassandra for storage... The list goes on and on. Each category (e.g. messaging, caching, storage) has many different open source software each has its own pros and cons. It is a challenge job for developers to decide which one to choose, and even difficult for them to switch from one software to another. DCAP intends to create a coherent runtime for distributed applications.
-
Transforming Applications into High-Availability Applications in Master/Slave Architecture. Is there a comparison between this model and the distributed cache (like redis) model (for example, from business intrusion, modification, performance, or expansion)? I understand that stateless application +redis mode can better cover this scenario.
- Yes. You can store object states in redis cluster. It makes your application code simpler, because redis cluster does the heavy lifting by providing master slave replication. This approach works. But it has a few downsides. First, you need to one more dependency (ie. Redis) in your application which will make your application more complicated and heavier. Second, it introduces more network traffic between application and Redis which hurts performance. Third the application is coupled with Redis. What if you are not happy with Redis cluster's master slave implementation? For example, Redis cluster today does not provide strong consistency - it may loose data under certain situation. To replace Redis with some other storage solution requires a lot of code changes. But with DCAP, if you are not happy with master/slave, you can replace it with RAFT with one line of code change.
-
Transform applications into scalable applications that support data sharding (Sharding). This is a load balancing strategy, based on cse sdk or mesher is also very easy to achieve.
- As far as I know, some microservice framework, e.g. Envoy, provides hash-ring based load balance. But hash is just one way to do sharding. We can provide more sharding algorithm, e.g. range based sharding. More importantly, request load balance is just one part of sharding. To do sharding properly, we also need to take care of cluster membership changes, e.g. add a server, remove a server, and rebalance between shards. Tasks like shard rebalance, in my opinion, will be pretty difficult for microservice framework. But it is doable in DCAP.
- Team Members:
| Name | Location | Vacation Plan in 2018 |
|---|---|---|
| Quinton | Santa Clara | 09/10 to 09/21 |
| Terry | Seattle | 08/06 to 08/17, 10/08 to 10/12 (tentative) |
| Michael | Seattle | |
| Sungwook | Seattle | 7/26-27, 8/9-10, +3 days in Aug-Oct TBD |
| Isaac | Seattle | |
| Srinivasch | India | 7/31 , 8/1-2 ,+6 days in Aug-Oct TBD |
| Prostil Prakash Hardi | India | 9/10 to 9/14 |
| Venugopal Reddy | India | |
| Neeraj Kuma | India | |
| Vishwajeet | India | 08/16 to 08/17, 11/05 to 11/06 |
| Naveen Sriram | India | |
| Jithu Thomas | India | 08/15 to 08/20 |
| Jeevan Kamkar | India | 08/30 to 08/31 , 10/22 to 10/25 |
| Preethi Kathamuthu | India | |
| Amit Kumar Roushan | India | 11/12 to 11/16 |
| Name | Location | Vacation Plan in 2019 |
|---|---|---|
| Quinton | Santa Clara | |
| Sungwook | Seattle | |
| Prostil Prakash Hardi | India | |
| Venugopal Reddy | India | 03/25 to 03/27 |
| Vishwajeet | India | 03/11 to 03/15 |
| Jithu Thomas | India | |
| Jeevan Kamkar | India | |
| Preethi Kathamuthu | India | |
| Amit Kumar Roushan | India | |
| Garima Gupta | India | 03/04 to 03/08 |
- Project Code: 9407991 - PaaS V200R003 Technology Development Project-US
- Huawei US Repo
- JFrog