The author | ZhangYe Ming

Dr. Almond CTO. Middle-aged programmer who focuses on various technologies and team management.

This article is based on the 10.22 GDG talk “Why Should Startups Embrace containers?” To sort out.

Four reasons startups use containers

In the first two articles (A Startup’s Path to Containerization (I) – Before Containerization, a Startup’s path to Containerization (II) – Containerization) we covered the evolution of the Almond architecture. Let’s review the three technical challenges that startups face at the beginning of the first article:

  1. How to build the system quickly and cheaply while ensuring security and stability?

  2. How to quickly build and publish applications to meet business requirements?

  3. How to improve team development efficiency and ensure development quality?

Almonds are containerized to address these challenges, with some success, but no perfect solution. After all, we are still small, and many solutions are just good enough for our specification. But in the process, we still deeply understand the value of containerization. As I said when I introduced containers, containers, like containers, will become a standardized infrastructure that will revolutionize upper-layer applications.

A lot of big factories actually began to do containers a year or two ago. But now we think it’s time for startups to consider application containers, too, for several reasons.

1. Container ecosystem has matured, container services and container cloud can significantly reduce the cost of container use.

Last year’s container choreography was not very mature, as Kubernetes, for example, still had some flaws. But after a year of rapid growth, Kubernetes has matured this year, and many companies are using Kubernetes in their production environments. Deployment and operations are much easier than before.

On the other hand, major public clouds have also launched container services, and there are many independent container cloud companies. If you use the public cloud, you are advised to directly use the corresponding container services, which can quickly set up the system, greatly reduce o&M costs, and improve efficiency.

And this brings an added benefit because these container services are based on Kubernetes, and container itself is a standardized thing, using container services can reduce the dependence on public cloud services. It is not difficult to migrate between container services in the public cloud, or to build and migrate them later.

2. Containers make it easy for startups to apply industry best practices and create premium apps.

A few years ago someone came up with a twelve factor application best practice that I think is a good standard.

These twelve practices are analyzed in the following list, which I break down into three situations, represented by three stars, two stars and one star.

  • ★★★ : It is difficult to practice without containers, and can be easily implemented in a container environment.

  • ★★ : Can be done without a container, but can be done better or more easily in a container environment.

  • ★ : No container can also practice, container environment can also support.

Best practices support instructions
Base code: One base code, multiple deployments. End to end Not only can one piece of code be deployed in multiple ways, but containers can be deployed in multiple ways in one image.
Dependencies: Explicitly declare dependencies. U u u The container manages internal dependencies through Dockerfile to achieve self-inclusion. Container choreography manages service dependencies.
Configuration: Stores configuration in the environment. End to end The container passes configuration through environment variables; Container choreography can provide standard configuration tools.
Backend services: Treat backend services as additional resources. u
Build, Publish, Run: Strictly separate build and run. End to end Built by Docker build, run by Docker run, strict separation.
Processes: Runs applications as one or more stateless processes. u Stateless containers should be perfectly supported, and stateful applications are now perfectly supported.
Port binding: Provides services through port binding. End to end Container choreography handles service dependencies and bindings, and applications no longer need to care.
Concurrency: Scaling through the process model. U u u Container choreography can be easily expanded.
Easy to handle: Fast startup and graceful termination maximizes robustness. U u u Container choreography supports fast startup, graceful termination, and self-healing.
Development environment is equivalent to online environment: keep development, pre-release, and online environment the same as possible. U u u Containers are portable and self-contained, and can run anywhere, but the application environment remains the same.
Logging: Treat logs as a stream of events. End to end Containers and container choreography support logging well.
Administrative processes: Background administrative tasks run as one-off processes. u Container choreography provides a variety of ways to run one-time tasks.

As you can see, these twelve elements can be easily implemented in a container environment, making applications easier to develop, maintain, and deploy.

3. Containers enable startups to apply microservices architectures at very low cost from the start.

This chart, which many of you may have seen, is Martin Fowler’s comparison of productivity trends for microservices and monolithic applications.

The point of this chart is that if the team uses microservices, it may take more effort to set up the infrastructure and architecture at first, but productivity can be maintained at a higher level. In startups, we tend to do Quick & Dirty for speed, which is to create a single app. This can be quick at first, but the problem is that individual applications become more and more complex and difficult to maintain, which can seriously affect team productivity.

When productivity drops to a certain point, teams start thinking about servitization (including us Almonds). However, in the process of servitization, more manpower and resources will be consumed and productivity will be seriously affected. After the completion of servitization, productivity will be improved to a certain extent, but it is difficult to reach the status of micro-service all at once, requiring continuous reconstruction and disassembly of services. So on the Internet, the productivity curve for most modestly sized companies actually looks something like this:

However, in a container environment, starting with microservices is not much less productive than a single application.

This is because the container already provides much of the infrastructure required for microservices, including service registration and discovery, service dependency and lifecycle management, load balancing, and more, as well as greater robustness and resource utilization. If the container cloud is used directly, the operation and maintenance costs are also low. In addition, the rise of tools and concepts such as SpringBoot and Service Mesh also provides a specification for microservice development, reducing the difficulty of development.

Of course, the business architecture of microservices is also an important aspect that needs careful consideration. But the design of the business architecture, which tests the architect’s ability and experience more, does not take much time on its own.

Therefore, in the container environment, we have no reason to create a single application, everything is micro services, as long as the business architecture is properly designed, the R&D team can focus on business development, and productivity can always be maintained at a high level.

4. Containers enable startups to reduce operation and maintenance costs, improve operation and maintenance efficiency, and easily practice Devops.

In a container environment, many routine operations are automated or at least semi-automated, such as deployment, release of new applications, expansion, and so on, and can be quickly responded to. The self-healing capabilities of container orchestration reduce human intervention, even in addition to problems.

Therefore, the operation and maintenance in the container environment is happy. Instead of helplessly and painfully responding to various demands, we can eat hot pot and sing songs to do things. Greatly enhanced the happiness of operation and maintenance, finally operation and maintenance students can be happy to fall in love.

Developers can also have more control over their applications. In addition to rapid and frequent deployment, data and feedback can also be obtained from logs and monitoring, and problems can also be debugged to a certain extent through tools.

The container is the future

Therefore, it is only in the container environment that microservices and Devops, which have become so popular in recent years, can work better. As mentioned in the previous article, container-based will gradually suggest a complete application architecture that will bring about revolutionary change.

The container is the future, and the future is here.

The full text after

You may also be interested in the following articles:

  • Lego micro Service Transformation (I)

  • Lego micro service Transformation (II)

We are looking for a Java engineer. Please send your resume to [email protected].

Almond technology station

Long press the left QR code to pay attention to us, here is a group of passionate young people looking forward to meeting with you.