Building a Microservice Architecture with Spring Boot and Docker, Part I

This is the first post in what will be a 4-part series on building a microservice architecture with Spring Boot & Docker. This post will provide an overview of what we mean when we talk about a microservice architecture, as well as the concept of containerization.

Part 1: Overview of Microservice Architecture & Containerization

What’s all of the hoopla about microservices?

As more products are being built around reusable REST-based services, it has been quickly discovered that splitting out your business functions into reusable services is very effective, but also introduces a risk point. Every time you update a service, you have to re-test every other service that is deployed along with it — even if you’re confident the code change wouldn’t impact the other service, you could never really guarantee it because the services inevitably share code, data, and other components.

With the rise of containerization, you can run code in complete isolation very efficiently; combining these two together allows for a product architecture that optimizes for fine-grained scalability and versioning, but at the cost of increased complexity and some duplicated code.

Isn’t containerization just the “new” virtualization?

Not exactly. It does share some similarity, in that containers and virtual machines are isolated environments that are managed by a controlling process (container manager and hypervisor respectively), but the primary difference between the two is that for each virtual machine, an entire stack of components are running — the Operating system up to the application server, and virtual hardware is emulated including network components, CPUs, and memory.

For containers, they operate more as fully isolated sandboxes, with only the minimal kernel of the operating system present for each container. The system resources of the underlying system are shared. The biggest advantage of containerization is the substantially smaller footprint means that for the same hardware, substantially more containers can be run than virtual machines. There are some key limitations of containers: the biggest one is that containers can only run Linux-based operating systems (this kernel isolation is Linux-specific technology).

Related to this limitation is that running Docker – the most popular container provider system — doesn’t run directly on Mac or Windows systems because they are not Linux. Instead, to run Docker containers, you need to start up a Linux Virtual Machine using VirtualBox, then run the Docker containers inside this virtual machine. Fortunately, the vast majority of this is managed by Docker Toolbox (formerly known as boot2docker).

Docker has received so much traction that the public repository of container images, Docker Hub, contains over 136,000 public images. Many of these are created by private individuals, some extending “official” images and customizing them to their needs, but others are entire platform configurations customized from “base” images. We will be leveraging some of these “base” and “official” container images for our study.

So we’ve talked microservices and containerization, but what part does Spring Boot play?

I’ve chosen to build my microservices using Java, specifically the Spring Boot framework. This was primarily chosen due to being familiar with Spring, and the ease of developing REST-service controllers, business services, and data repositories with it. This could just as easily be done in Scala with Akka/Play; one of the touted benefits of microservice architecture is full independence of the services, so it shouldn’tĀ matter what language or platform each is built and deployed in.

Personally, I think the maintenance costs of developing with multiple languages is greater than the gains of flexibility, but there are applicable use cases, such as one could be in a situation where one department within a large organization has chosen different technology stacks as “standard.” Another possible scenario where this benefit would apply is if you decide to transition from one language/platform to another — you can migrate one microservice at a time, provided the end web service interface remains the same. Some goals for this effort:

  • A start-to-finish guide to setting up microservices and Docker
  • Understanding the pros and cons of different decisions around the components surrounding this architecture — from source control to service versioning, and everything in between
  • Analyze “purist” microservice beliefs and see how they hold up when applied to a “real world” scenario
  • See if Docker lives up to the hype, and what is necessary to run Docker for professional development
  • Build a complete solution utilizing a series of microservices, each in its own container; a persistent layer, hosted in its own container; container clustering
  • Have fun

The business scenario that I will model is an employee tasking and recognition system at a software development company. The system covers the following tasks:

  • Employees log into the system
  • Employees see a list of required tasks/missions, e.g. write a blog post on emerging technology, attend a conference, perform code review
  • Employees submit completion of these tasks to their manager for approval
  • Employees receive “points” for completing tasks
  • Employees can spend points on rewards like company swag, free lunch 1:1 meeting CEO, etc.

This closes out part I pretty well — we have the beginnings of an understanding around microservices, containerization, and a business scenario that we will use as a backdrop for the rest of the discussions. As we move onto part II, we’ll get set up with tooling and dive into how to work with Docker and setting up our first container.

This blog is the first of four parts:

Dan Greene

Dan Greene

Director of Cloud Services

Dan Greene is the Director of Cloud Services at 3Pillar Global. Dan has more than 20 years of software design and development experience, with software and product architecture experience in areas including eCommerce, B2B integration, Geospatial Analysis, SOA architecture, Big Data, and has focused the last few years on Cloud Computing. He is an AWS Certified Solution Architect who worked at Oracle, ChoicePoint, and Booz Allen Hamilton prior to 3Pillar. He is also a father, amateur carpenter, and runs obstacle races including Tough Mudder.

8 Responses to “Building a Microservice Architecture with Spring Boot and Docker, Part I”
  1. Al Krinker on

    I definitely prefer Docker since as you mentioned it reuses resources and I don’t need to deal with heavy VM that creates its own OS, etc and you would need to install required components (java, etc) on each VM… while docker container would just reuse it.

    Great start. Looking forward for more content!

    Reply
  2. Nomaan Butt on

    Simple great work.

    Reply
  3. Code4 Kix on

    Thank you! I learnt something today.

    Reply
  4. James on

    Really very informative and interesting article.
    I am new to micro-services and I am really confused about micro-services, docker, spring-cloud. These terms are not clear to me. Let see what happen in next 3 parts.
    Can you please anyone clarify these terms?
    I mean how micro-services are different from REST-services?
    Whats the role of docker and spring-cloud in context of micro-services?

    Reply
    • Dan Greene on

      Those three things are all separate concepts – spring-boot is a framework for rapidly developing java applications, particularly MVC web apps (but many others). Containers/Docker is a mechanism for basically packaging your code, and everything needed to run it, into a deployable thing (container image), which can be run on any platform running a Docker agent (e.g. Docker machine, Docker swarm, Kubernetes, etc). Micro-services are an architectural/design pattern that breaks up your product application into small, atomic units, which are self-sufficient, and communicate with each other via lightweight protocols like REST. You can see how each of these terms are all part of a related perspective and approach to product software development.

      Reply
  5. Knowlengr on

    I think this info on Windows containers and Docker interop for Windows is dated. See https://blogs.msdn.microsoft.com/webdev/2017/09/07/getting-started-with-windows-containers/

    Reply
    • Dan Greene on

      A fair point – but at the time this article was originally written (October 2015) it was correct. I’m very happy with ‘native’ Windows and Mac Docker. Yes, behind the scenes they are still running a VM – but they’ve made it seemless so it looks, acts, and in most ways, is running natively. Docker was one of the first 5 software items I installed on my new personal windows laptop. Combined with Ubuntu running on windows (which can directly call the docker.exe program if you set path/aliases correctly) – it is a great time to like containers!

      Reply
Leave a Reply