Microservices Architecture Explained to Your Mom
When we talk to our writers about our “writing style” at Nanalyze, we often describe it as “explaining a technology concept to your parents and then expecting that they’ll ask you how they can invest in it“. There is no technology out there so complex that it can’t be explained to the average layperson. We don’t just assume prior knowledge. We always start from the ground and work our way up. This brings us to the topic of our article which is “microservices architecture”. On the surface this sounds horribly mundane but we’re going to try and explain this domain to you without boring everyone to tears.
Same Same But Different
A while ago we wrote an article about fog computing which talked about how at first, computer software was deployed on a central mainframe. Then you used “dumb terminals” to connect to that central mainframe from anywhere. This was considered to be “centralized computing”. Then when the price of computer hardware fell we decided that we should all own a snazzy 486 DX 33 MHZ which we would equip with our own software to run. Computing then became “decentralized”. Then we decided that everything needed to go into “the cloud” and things became “centralized” all over again. Then we decided that was too “top heavy” and regressed back to decentralization with “edge computing”. The lesson learned here is that in the software world, we like to use lots of cool nomenclature to describe what’s new when in fact it’s much of the same thing we’ve always been doing.
Software Architecture – The 3-Layer Approach
You all know what software is. The browser you’re using to read this article is a piece of software which resides on an operating system which is also a piece of software. Everywhere you look now you see software. People that build that software nowadays aren’t highly paid software engineers in developed markets but increasingly low paid “emerging market talent” found in places like Mumbai. What all these people have in common is that they understand languages that tell computers what to do. The way they use that language to build software is often called a “software architecture”. If you’re old school, you’ll remember a simple software architecture known as the “three layer approach”:
That approach you see there was how we used to build software applications. The entire application resided across all three layers. When you wanted to release a new version of an application, you had to replace all three layers at the same time. If you updated one but didn’t update the others, it would break. We call those software “defects” or “bugs”. Building flexible software that scales is far more difficult than most people think. That’s where “microservices architecture” comes in.
The concept behind microservices is really easy to understand. Let’s use the Nanalyze website ads as an example. If we use the “3 layer approach“, then the presentation layer is how the ad is displayed in the article. The logic layer determines which ads to show you. The data layer is the actual ads themselves. If we wanted to change the way our ads behave, we’d have to make changes across all three layers. Instead, let’s just create one software program with all three layers that does nothing but service ads. Because its only job is to serve ads, it’s consequently very scalable. Moreover, anyone can use it. That’s exactly what Google does. When you do a Google search, it actually calls up to 70 microservices.
According to the smart brains over at Sequoia, there are three reasons for the emergence of microservices architecture
- Containers – This is just a way to package software to make deployment easier. Nothing that new and exciting here really except that it makes it easier to deploy software without breaking things.
- API – This stands for Application Programming Interface and it’s just a simple way for people to share their software. Let’s say you have an expensive computer vision application and I want to use it. You can just tell me how to access it through an “API” and then I can easily integrate that functionality in my own software application.
- The Cloud – Everything is being stuffed into “the cloud” because it makes a whole lot of sense to share expensive computer hardware rather than buy your own.
In the same article, Sequoia also put together this handy “microservices ecosystem” diagram which shows all the technology providers that are benefiting from the emergence of microservices architecture:
The Benefits of Microservices Architecture
Everything comes down to benefits, which in most companies mean reduced costs and increased revenues. Microservices architecture can supposedly increase revenues because it enjoys greater uptimes. Why greater uptimes? Because when you have all your software components decoupled then you don’t have a single point of failure that can take your whole application down. If something fails, it will only be a single component and you can always just switch it out quickly with another provider of the same service. This same benefit extends to being able to make changes very quickly in your own microservice without worrying about breaking the entire application. Lastly, cost reduction comes into play in the form of reduced hardware needs. According to Sequoia
A thoughtful approach to microservices can result in far more efficient use of code and underlying infrastructure. Users report significant cost savings—in some cases reducing the amount of infrastructure required to run a given application by 50%.
That should make for an easy sell to any CIO.
Service-Oriented Architecture (SOA) vs. Microservices
If you’re the least bit involved in software development, you’re going to be familiar with something called “service-oriented architecture” or SOA which was popular in the last decade. What is SOA? The concept is exactly the same as microservices architecture except that there are some fundamental differences that could be best described as “SOA is more complex than microservices”. Complexity is something that any software developer would see as a detriment. Software development is already so incredibly complex that anything which brings simplicity is welcomed with open arms. If you’re still interested in learning more about the difference between the two architectures, download this free 43-page e-book by software architect Mark Richards. Or you can just do what we do and casually mention at cocktail parties that you believe “microservices is really just SOA done right“.
Now that you understand all about what microservices is, you’re probably realizing that it’s less about something tangible and more about something abstract. Microservices is a new way to build software but fundamentally nothing new whatsoever. It’s just a decentralized software architecture that allows you to be “constantly on” and flexible enough to immediately adopt the latest and greatest software modules being developed. If you don’t work in software development, it isn’t something you’ll probably come across again. But if you do happen to come across it again, it will no doubt have found a much more exciting label.
If you enjoyed this article, then sign up for our free newsletter - Nanalyze Weekly. About every week, we'll send you a simple summary of all our new articles. If you didn't enjoy this article, share it on Twitter and tell everyone how much you hated it.