Containers are much smaller than VM instances and are easy to quickly deploy, either locally or in the cloud, and can be spun up or down to match demand and available resources.
The appeal of containers for microservices should be obvious: Each individual microservice can run in its own container, which cuts the overhead of managing services significantly.
Most container implementations have complementary orchestration tools that automate the deployment, management, scaling, networking, and availability of container-based applications. It’s the combination of small, easy-to-build microservices and easy-to-deploy containers that makes the devops philosophy possible.
There are several implementations of the container concept, but by far the most popular is Docker, which is generally paired with Kubernetes as an orchestration platform.
Spring, while popular, is tied to the Java platform. Container-based systems, on the other hand, are polyglot: Any programming language that the OS supports can run in a container, which gives more flexibility to programmers.
Indeed, a big advantage of microservices is that each individual service can be written in whatever language makes the most sense or that developers are most comfortable with.
Indeed, a service could be completely rebuilt in a new language without affecting the system as a whole, as long as its APIs remain stable. DZone has an article discussing the pros and cons of Spring Cloud vs. Kubernetes for microservices.
Microservices design patterns
No matter what language you use to develop microservices, you’ll face issues that other developers have encountered before.
Design patterns are formalised, abstract solutions to recurring problems in computer science, and a number of them are specifically for microservices. Devopedia has a great list, which includes:
- Service Registry: for connecting clients to available instances of microservices
- Circuit Breaker: to prevent failed services from being called repeatedly
- Fallback: for providing an alternative to a failed service
- Sidecar: for providing an auxiliary service to the main container, such as for logging, synchronizing services, or monitoring
- Adapter: to standardize or normalize the interface between the main container and the external world
- Ambassador: to connect the main container to the outside world, such as for proxying localhost connections to outside connections
Microservices and the cloud: AWS and Azure
As noted above, one of the advantages of using containers is that they can be easily deployed to the cloud, where flexible compute resources are available so you can maximise your application’s efficiency.
As you might imagine, the major public cloud vendors are all eager for you to use their platforms to run your microservice-based apps. For more information, check out the resources from Amazon, Microsoft, and Google.