Clouds: Build a Serverless application with Docker
Martin interprets Serverless:
Serverless does not mean that there is no server, but from the application can be in an abstraction layer to ignore its existence, but only focus on the implementation of the function and their own request processing; each function is not a simple business logic to deal with the code, On the contrary, each function call has the characteristics of Server, evolved into a self-conscious, self-knowledge and autonomy of the workload unit; they are more like to be able to derive other new functional unit of the organism. So that the entire Serverless application architecture, each life can be derived, sub-grandfather infinite also.
This article is compiled: https://blog.docker.com/2016/0 … cker / The following is the text content.
In this ever-changing technology, the new wave of technology often threatens and subverts the current technology. In the preparation of the application we often talk about the "Serverless" technology. Its core idea is to deploy the application as a series of functions / functions, which are deployed on demand when needed. Server management should be no need to worry about things, all functions are called on demand, is running on top of the cluster.
But Serverless does not mean that there is no Docker , in fact, "Docker is Serverless." You can use the Docker to container these functions, and then run on the Swarm cluster as needed. Serverless is a way to build distributed computing applications, while Docker is the perfect way to build and run their platforms.
From Server to Serverless
So how do we write Serverless apps? Let's take a look at this example: "A voting application with five subservices" :
Its structure is as follows:
1. Two Web front ends
2. A background handle to vote for the Worker service
3. A message queue that handles voting
4. A database that background processing voting process is very easy to become the goal of conversion to Serverless architecture. In the voting application, we can run a bit similar to the following code to perform background tasks:
Worker and Message Queuing can be replaced with on-demand containers running on Swarm and automatically expand on demand.
We can even eliminate the Web front end. We can do this: use the Docker container to correspond to each HTTP request, and each HTTP request is handled with a self-growing container running a lightweight HTTP server. Previously, the HTTP server, which was running for a long time, now becomes an on-demand container with HTTP corresponding and processing power, and they are automatically scalable to support all access requests.
Our new architecture is probably as shown in the following figure:
Where the red box is a long-running service, and the green box becomes a Docker container that is called on demand. This application becomes only a handful of long-running services that need to be managed. When using the native Swarm expansion capability at the time of the request, the upper limit of the processing power is the upper limit of the Swarm cluster.
How to achieve
There are three useful tips that you can use in your program:
1. Use the code in your code as a Docker container on demand
2. Use Swarm to run these containers on the cluster
3. Run these function containers from the container, bypassing a Docker API socket
Using the combination of the above techniques, the possibility of program execution load will be related to how you structure your application. Running the background task is a very suitable example, but the other applications in the entire workload is also possible, for example:
1. Considering the delay, it may not be realistic to start a container to serve all users' HTTP requests. But you can write a built-in load balancing logic to let it know when to actively expand the Web front end itself automatically by running more web processing containers on the Swarm cluster.
2. A MongoDB container can be used as a self-built architecture on Swarm, which automatically runs the correct number of shard and replica containers.
We have got these radical new tools, used to build the application of the abstraction layer, we vaguely see how the possibility of deep down. We still have to build applications on a bunch of servers for a long time, and later we can use Swarm to perform functional code on any place in the infrastructure as needed.
Hope that these will give you some new ideas on how to build your application, but we still need your help. We already have some of the basic functions of building Serverless applications, but they are still not very complete, we need better tools, libraries, sample programs, documents and so on.
This Github library has links to tools, libraries, code and articles . Based on this, if you want to learn more, please share any relevant links so that we can start collaborating together.
This article comes from: http://www.youruncloud.com/blog/69.html
Friends interested in implementing Docker container technology or container production are welcome to discuss group discussions. We brought together Docker container technology to implement the team elite and industry technology to send high, online to share your Docker technology dry goods. Our mission is to have a more professional platform to exchange Docker combat technology, we will regularly invite guests to do all kinds of topics to share and review, common practice study Docker container ecosystem.
Plus micro-credit method:
1. Concerned about [ have cloud ] public number
2. message "I want to add group"
QQ group number: 454565480