Making the jump from monolithics to microservices

Written By Daniel Oostra

As companies begin to find more ways to save money and operate more efficiently, technology leaders are making key changes to their architectures as they develop applications. These changes offer a huge opportunity for developers to leverage their skills as programmers–and to enhance their skill sets with new DevOps practices and technologies.

Similarly, backend engineers are looking to boot camps and schools to add programming and coding skills to their resumes to make them more versatile and to be able to communicate with the developers and programmers working on applications on the platforms they support.

Just today I spoke with a systems administrator, Robert B., who also was trained to be a cloud security specialist and was interested in Coding Dojo. He was talking to me about how he could shell script, but his knowledge of compiled languages and practices were a complete mystery to him. He brought up containerization in his interview and stressed the desire to learn more about microservices. We had a great discussion and hopefully, we will have him join us at our onsite boot camp in March 2019.

My discussion with Robert prompted me to write this piece. As developers, instructors, and technologists, we need to investigate the shift that has happened in how applications are being developed and supported. To gain a good understanding of the architectures we are discussing, let’s begin by taking a look at what I mean by monolithic; then we can examine how microservices fit into the big picture of application development.

Monolithic Architecture

Today, and in the past, computer programs that have a monolithic architecture are built using a single unified software design model; where all the parts of the program are put together in one piece.

One challenge when working with this sort of software is that when you need to change one feature or function in the software, you might need to re-write the entire program to make that new change work.

That sounds tedious–and believe me, it can be. However, monolithic architectures are not all bad, applications developed this way can be easier to debug since all the parts are encapsulated in one location. They can be more secure since its’ not connected to external systems, and you can maintain total control of the content and experience that you provide your users.

When thinking about what a monolithic application is, think back to an old school arcade game like Centipede, Ms. Pacman, or Space Invaders. The game is played right there, you have one way to interface with it, you have different high scores (state), and the game changes the score data over time (state change). If the game makers want to change the user interface, they would have to re-engineer the entire game. Remember the desktop versions of Word and Excel? Microsoft took its monoliths and moved them to a microservices architecture with its’ launch of Office 360.

Let’s look at a more abstract example. Understanding what a monolith is the first step in understanding how to migrate to microservices. These types of applications take the user interface, the data access layer, and the data store and tightly bind them together into what we call a stateful application. All that means is that we have an application that stores and changes data over time and that the app can have what we call state. The key takeaway is that the state of these applications can and will change.

Modular Architecture

Now let’s look at a modular application. In the diagram below, we have a similar application compared to the one above, but, notice how on each layer of the application, there are multiple components. Now imagine if each component was completely independent of the rest of the system.

Look at how easily things could theoretically scale. In contrast, the monolithic application would be very hard to scale because there is no way to add additional components to the system in a way that would not break the rest of the system. With a modular approach, we can add components on each layer and grow the application to fit the exact needs of our clients. If we need more of something, we just plug it in and turn it on.


Computer scientists have been working with this sort of approach for a long time. We call it orthogonal design, which is just another fancy way to say modular design. Creating applications with orthogonality in mind is not just for computer scientists, we can use it in all aspects of engineering. We can take this approach and develop websites, mobile applications, and even desktop applications using modules and services that are available on the web via APIs.

Microservices

Now that we have all the background out of the way, it is clear from my perspective why anyone would take their application the modular route. My definition for what a microservice is that it is any program that serves a single function or discreet task, and can be integrated into any application seamlessly and easily, regardless of the platform. I’ve read other definitions that define a microservice is any service that only requires one team to maintain it.

Wikipedia defines a microservice as:

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.[2] It also allows the architecture of an individual service to emerge through continuous refactoring.[3] Microservices-based architectures enable continuous delivery and deployment.[4]

Wikipedia. (2019 Feb 12) Microservices, https://en.wikipedia.org/wiki/Microservices

We all play video games, and today, many of our favorite video games are collections of microservices.

Think about when you play Fortnite, do you think the Fortnite people wrote their own chat protocols and program to work in their game? Or, maybe when they get an additional million users, do they go out and buy more servers?


Of course, they didn’t, they tapped into a microservice that provided that service and saved them thousands of dollars in design, testing, and development, mainly because someone else spent all the time and money to develop that service. As illustrated in the diagram above, as the number of users increases, the “orchestration software” responds by turning on another service to handle the loads. Each one of the chat microservices can operate on their own and with other units, if something bad happens in one, then we just shut it down and the system continues without notice.

Virtually any program can be broken up into components that could be running in different rooms, cities, or countries. This all goes back to orthogonality and creating tools that can be reused, over and over again.

Preparing Our Teams

How do we make the most effective and efficient system from monolithic design to a microservices approach? We train our people. Taking our current teams of developers and systems administrators and exposing them to the benefits of this approach is the key. Once technologists see the savings in maintenance and support for older architectures, they will move their products to leverage secure, working microservices to scale and grow their online footprints.

Coding Dojo exists to assist the technical staff of your organization to make the migration from your monolithic architectures into the microservices environment. Currently, our instruction team is busy working on curricula that will support your organization’s transition, providing the tools and experience that will give them the vision to see the pitfalls and challenges of a software migration–before they start costing your organization precious resources.

With courses on containerization, microservices orchestration, and modern DevOps practices, let Coding Dojo’s corporate training team help your staff chart a clear and well-thought-out path to increase your organization’s technical efficiency and to develop a solid roadmap to saving money using microservices.