Table of Contents<\/p>\nToggle<\/span>

Deploying microservices is still challenging<\/a><\/li>
Packaging a Spring Boot app as a Docker image<\/a><\/li>
Testing and pushing Docker images to production<\/a><\/li>
CI and production environments<\/a><\/li>
Easier with a PaaS<\/a><\/li>
Want details? Watch the video!<\/a><\/li>
Further reading<\/a><\/li>
Relevant slides<\/a><\/li>
About the speaker<\/a><\/li><\/ul><\/nav><\/div>\n
<\/span>Deploying microservices is still challenging<\/span><\/h3>\n
According to Chris Richardson<\/a>, while all the previous Spring releases only added minor changes to the framework, Spring Boot has simplified deployment of apps and introduced a lot of useful features, for instance, auto-configuration.<\/p>\n
Spring Boot \u201cbasically gives you an opinionated way of building a Spring app and it makes it very easy to create standalone, production-ready apps.\u201d<\/em> It \u201canalyzes the class path that you use to figure out what components are necessary and then finds them for you.\u201d<\/em> That is very convenient if you have to constantly re-define services.<\/p>\n
Despite Spring Boot simplifying a lot of things, the reality of deploying a microservices app remains complex. If you package it with RPM, you may still have to deal with dependency version concerns, conflicting ports, etc. That\u2019s where immutable infrastructure comes into play.<\/p>\n
$\"Deploying$ <\/center><\/p>\n
There are several ways to implement immutable infrastructure\u2014e.g., package the app as an AMI. Unfortunately, AMIs are generally slow and not really portable. In addition, they can weigh gigabytes and are impractical if you want to run multiple VMs\u2014not so good for a distributed system.<\/p>\n
\u201cThis is what got me interested in Docker. Docker is an incredibly light-weight OS-level virtualization mechanism\u201d<\/em> that runs on top of Linux. The main advantage of Docker over AMI is speed:<\/p>\n
\n
Docker images have a layered structure that facilitates sharing and caching between them.<\/li>\n
Although Docker images do contain the entire OS, the only thing that is ever booted is the Java executable, so the start-up is lightning-fast.<\/li>\n<\/ul>\n
<\/p>\n
<\/span>Packaging a Spring Boot app as a Docker image<\/span><\/h3>\n
Chris Richardson continues by describing the mechanics of working with Docker images. The first step is preparing a minimum Dockerfile (the recipe), which can be obtained from Docker Hub<\/a>, a giant community-supported repository of Docker images. Then you need to specify the base image, add the required metadata, indicate what port will be exposed to the outside world, set the commands that will run on start-up, and copy the .jar file into the image that you want to build.<\/p>\n
$\"Spring$ <\/p>\n
The build process involves creating a new build directory, copying the .jar file created with Gradle into the build directory, and running the -docker build<\/code> command against it. The directory is then sent to the Docker daemon to build the Docker image.<\/p>\n
The docker run<\/code> command is used for running apps packaged as Docker images. This is the step where you can specify how the image will be run, its name, port mapping, etc. One of the cool features provided by Spring Boot is that you can set configuration properties through OS environment variables. This means you can define external config properties inside your Docker container (using the -e<\/code> argument). For instance, if your app uses MongoDB and RabbitMQ, you will can tell it the coordinates of their servers (see the slide below).<\/p>\n
<\/p>\n
<\/p>\n
<\/span>Testing and pushing Docker images to production<\/span><\/h3>\nThe second half of the talk provides some details about the microservices app built by Chris Richardson using Spring Boot and Docker. The architecture features services written using Scala and Spring Boot and a Node.js-based API gateway. Each of the services uses a Jenkins CI<\/a>-based build pipeline.<\/p>\n <\/p>\n Testing Docker images is fairly straightforward. Thanks to the nice the REST API of the Docker daemon, it is possible to use HTTP to create and start containers. During smoke testing, you start a container, ping an URL, shut the container down, and delete it.<\/p>\n The next step is to push the Docker image to a hosted registry (e.g., Docker Hub). To do that, you need to tag the image with the hostname and port of the registry. The process is nicely optimized thanks to layering and only takes 25 seconds. After the image has been published, you can pull and run it in the production environment. Pulling also takes about 25 seconds.<\/p>\n <\/p>\n <\/span>CI and production environments<\/span><\/h3>\nThe last part of the talk was dedicated to the details of the continuous integration and production environments used by the microservices application.<\/p>\n The CI environment consists of Jenkins and Artifactory, which are running as Docker containers on AWS EC2. A separate EBS volume hosts \/jenkins-home<\/code>, \/gradle-home<\/code>, and \/artifactory-home<\/code>, so that the state is not lost every time the container is restarted. Gradle is also externalized to speed up the build process.<\/p>\n The production environment consists of an EC2 instance. Updates are done with a Python script that finds outdated images in production using the Jenkins API and then updates them by SSH-ing and running docker pull<\/code> to download and install a new version of Docker.<\/p>\n\u201cIt\u2019s like five seconds to build an image, 25 seconds to push it, 25 secs to pull it, and then it takes 10 seconds to start. So, that\u2019s 75 seconds from build completing and it actually running in production.\u201d \u2014Chris Richardson<\/em>\n<\/p><\/blockquote>\n The bottom line is that Docker containers are a lot faster and more convenient for running microservices than AMIs. Therefore, it is not surprising that Docker is so popular and has already been enabled on several clouds, such as AWS and GCE.<\/p>\n<\/div>Altoros Take<\/div>\n<\/span>Easier with a PaaS<\/span><\/h3>\nMicroservice architectures enable easy scaling, a possibility to evolve different parts of the system independently, using any languages and frameworks, high availability, and other cool features. What is more important, they enable faster innovation\u2014something that everyone wants. But nothing in this world comes for free. Managing numerous small services and their multiple copies, which you need for failover or to handle large workloads, can be a nightmare.<\/p>\n In addition, this architectural style may lead to increased operational overhead. To address these downsides, you need to provide a high level of automation\u2014e.g., by using a PaaS.<\/p>\n A platform, such as Cloud Foundry, can automate service management, provide containerization, improve server utilization, and take away most of the pain associated with running complex distributed systems.<\/p>\n In a related presentation, this talk<\/a> by Russ Miles of Simplicity Itself gives a great in-depth overview of how PaaS and microservices fit together. Or, read our guide<\/a> on microservices, including Cloud Foundry examples.<\/p>\n<\/span><\/div><\/div><\/div><\/div><\/div><\/div>\n <\/p>\n <\/span>Want details? Watch the video!<\/span><\/h3>\n\n\n\n\n\nTable of contents<\/strong><\/p>\n \nWhat is Spring Boot? (46’45”<\/a>)<\/li>\n Why immutable infrastructure \/ containerization is so great? (53’13”<\/a>)<\/li>\n How Spring Boot works with Docker (55’38”<\/a>)<\/li>\n What does a Docker- and Jenkins CI-based deployment pipeline look like? (70’06”<\/a>)<\/li>\n How to deploy a Spring Boot-based microservices with Docker? (72’14”<\/a>)<\/li>\n<\/ol>\n<\/div>\n<\/div>\n