It’s been a while since the enterprise realized that many hands make light work, and with containers and open source technology, anyone interested in transitioning to microservices has a virtual encyclopedia of companies that have gone that path before them. A lot of people feel that when you break open a monolith, all these neatly packaged microservices are going to come bouncing out. That isn’t really the case at all. Let’s take a look at three companies that attempted transitioning to microservices with varying degrees of successes and failures.
Copious: Learning how to fail at microservices
Copious was formed in 2011 when several colleagues got together to create, a social marketplace using Rails and some backend services. Rails is a model view controller (MVC) framework, providing default structures for a database, a web service, and web pages. It encourages and facilitates the use of web standards. Rails emphasizes the use of other well-known software engineering patterns and paradigms, including convention over configuration (CoC), don’t repeat yourself (DRY), and the active record pattern.
The product used a social network graph, which is an overlay of everything they know about someone from social media and allows publishing stories to social channels. A social network graph lets users use the constant study of social networks to their advantage. Some of them even come with the capability of merging network data from two different users, giving users of this application a way of interacting with each other and complement each other’s information.
The first problem they encountered with their monolith was that because they were ingesting data from everyone else’s social graph, they already had terabytes of data on Mongo and EC2. This was way more than they were processing with the monolith and 200K records of that data was just authentication tokens, required to allow users to access their site. This was causing the service to keep collapsing and was preventing users from getting to the site.
Additional troubles arose from the fact that customer’s actions on the site like buying, seeing, or viewing, were not being saved as backend external data but rather were being added to the monolith. So when users wanted to check something like a review, they had to merge two giant monoliths on a Rails web server, which in their own words, was a complete disaster.
Now with a monolith, all that data coming in was being processed as one data type. While in reality there were three different sets of data inside that social data. The graph of personal connections, the management of OAuth token interactions so users could sign in with Facebook or Twitter connect, and Token storage for those interactions. So in effect, they had one frontend monolith and another backend monolith supporting it.
Sometimes it’s best to cut your losses than get yourself deeper in microservices architecture, especially if you’re not ready. And that’s exactly what they did at Copious.
They merged everything back into the monolith sort of like a system restore to when they remembered how things functioned. This shows that if you don’t have a clear understanding of your business, product, or where you fit in the stack, breaking things out prematurely into a bunch of services without knowing how they are going to be used is not going to be a fun outcome.
We chose this story first not as an example of failure but rather an example of where taking things for granted can get you with microservices, and to restate that it’s not all sunshine and roses and the possibility of failure is very real indeed. The next lesson, however, is a happy one about a little note taking app called Evernote and its journey to GCP.
Evernote: Microservices in the Google Cloud
Evernote started small and first migrated successfully to the cloud before much later making the change to microservices architecture. This is a great way to gain familiarity with a new platform and perform basic testing before jumping “all-in.” Though this is an important step, it by no means confirms that your production service will run the way you intend it to.
During the migration, the first thing the team at Evernote realized was that it really helps if you have an application/system where you can separately migrate individual parts or components. This means it was extremely difficult to migrate their older, monolithic application stacks, which was where the decision was made to change the monolith to a bunch of microservices, so future migrations would not be as painful.
This brought them to Kubernetes as their choice of orchestration framework, which is a great place to start. They then decided to leave the daunting task of running a production-grade Kubernetes cluster to Google Container Engine (GKE). This is a great example of how to realize when you’re out of your depth and pay for professional help.
Instead of a total rewrite, incrementally refactoring your monolithic is a good way of transitioning to microservices architecture. This means you gradually build a new application consisting of microservices, and run it parallel to your monolithic application. Over time, the amount of functionality implemented by the monolithic application shrinks until it either disappears completely itself becomes one of your many microservices.
Martin Fowler refers to this application modernization strategy as the Strangler Application. The name comes from the strangler vine which is a kind of fig vine found in the rainforests. A strangler vine grows around a tree in order to reach the sunlight above and often slowly strangles the tree to death.
Cloud Elements: Transitioning to microservices gradually
Gradual application modernization follows the same pattern and a new application consisting of microservices is built around the legacy application to slowly strangle it out of existence. An example of an organization using this method Cloud Elements. They decided to start transitioning to microservices with parts of their platform a little over a year ago.
The path Cloud Elements chose, as mentioned above, was to slowly distribute independent microservices functions from their monolithic platform. This was done by first distributing compartmentalized pieces of their platform to run as microservices, while continuing to run the current core monolithic platform simultaneously. Their final goal was to have the monolith only exist to support their core platform API and Elements, while all other functions scale as microservices.
The whole idea here is to replace functionality slowly without shocking the entire system and can be compared to slowly training plants to grow a certain way. Like the vine example, minimum and discrete changes are made to the system where the tree does not realize it is being strangled and slowly the monolith hands over power to the microservices completely.
Thus, we have seen three examples of different approaches to transitioning to microservices architecture. The first was a blind leap for the purpose of “everyone else is doing it” and resulted in a painful backtrack back to the monolith. The second was an “all-out” approach, where everything was outsourced to professionals, and the third was an organization that did the migration themselves successfully by gradually building microservices around their monolith.
In this way, any organizations looking at transitioning to microservices in the near future have hundreds of examples available to them, though each one reiterates the fact that each DevOps journey is different and unique in every way.
Photo credit: Shutterstock