How did we get from legacy to microservices?

Ever wonder why a microservices based architecture came to exist? I often find it useful to understand the evolution of how technology came to be. In doing so, there is great understanding.

If we go back to the before times then we will find that application architecture was relatively simple. Most applications used a 3 tier design that would consist of a client, server and database. You had the client that the user used to connect to the server and display information. You had the database that contained all of the information that needed to be stored. Finally, you had the server that contained the logic for both backend and frontend calls.

We created multiple environments in order to have a level of redundancy and keep some semblance of uptime. A load-balancer would front-end these servers and send traffic to the different environments.

This was an okay solution when applications were updated quarterly and there was a lot of time to plan and test. Times have changed and needs have shifted. We now live in world ruled by SaaS (Software As A Service). The rules of engagement have changed. Consumers of applications need the latest features ASAP in order to push out their new widget and track that widget and ascertain the full lifecycle of that widget. I digress. But, You get the point.

Application design and architecture has changed to. At one time all calls were internal to the server and very little communicated to outside services. Now we live in a API centric world in which we consume most services through them. Smart developers are also looking to get the job done the easiest and quickest so APIs allow that to happen.

Developers are now having an easier time implementing APIs because of standards like OpenAPI spec. Developers started to think about loosely coupling their apps and deconstructing them like a trendy entree. What used to be libraries that were called from a single monolithic app are now designed to be micro-services and are split out by function. This allows developers to work on a single component of an application and they can update that piece, by itself, without effecting other components.

We can now decide where services should run and how they should communicate now that the services are split out by function. Additionally services can be scaled out so that they can handle additional load and traffic. We can now introduce services slowly and quickly phase them out if they are functioning improperly.

Hopefully this article highlights some of the core aspects of the shifts that occurred that led to micro-services based architecture.

Now that you a little bit of the history here is an article with some great information on how to determine the resource limits for a new microservice.
https://dev.to/ciscoemerge/determine-resource-limits-for-a-new-microservice-471

Check out some of our open-source solutions:
https://eti.cisco.com/open-source