Transitioning to Microservices: The Story of Two Monoliths - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
DevOps
Commentary
5/25/2017
01:30 PM
Rob Zuber, Chief Technology Officer, CircleCI
Rob Zuber, Chief Technology Officer, CircleCI
Commentary
50%
50%

Transitioning to Microservices: The Story of Two Monoliths

Now is a great time to be thinking about architecture, but it's also important to do it in a way that is incremental and allows you to test ideas and validate them.

I started my career writing macros in Microsoft Excel. So, while I didn’t know how to write software, I could record macros for the things that I needed to do and go back to figure out how to change and edit things. It’s through this lens that I would like to tell a story of monoliths and microservices: Sometimes it is necessary to simply do whatever it takes to get the job done.

In engineering as a community, we’ve developed a great ability to revise history. The industry as a whole has the tendency to write blog posts and books about the perfect outcome -- as if we knew what we were doing the whole time -- when the reality is, no one had a clue. We’ve seen this same phenomenon with microservices.

In the world of microservices, there are two main viewpoints. One is the idea that a company should build its entire platform in microservices because Netflix and Amazon did it and they’re successful. The other viewpoint is the idea that as a start-up that needs to move fast and iterate quickly, microservices get too complex.

So, maybe you start with a monolith, scale and figure out your business until one day you realize you need microservices. The next thing that happens is you break open the box and all these services come out of nowhere and you have a perfect microservices architecture and move forward with that, right? That seems to be the consensus if you read the literature, which makes it seem like everything was perfect all along and we figured it all out. Except, that’s not the way it goes.

A cautionary tale of starting with services

In 2011, several colleagues and I started a business called Copious, a social marketplace. Using Rails and some backend services, the product used a social graph -- an overlay of everything we knew about someone from Facebook, Tumblr, Twitter, etc. -- and would allow publishing stories to social channels.

We concluded early on that all of this external data from social platforms would make sense as a service. As a smart group of engineers with a certain set of context, we decided that since people are now doing microservices, it made sense to go down this path. But the reality was that we actually had three different sets of data inside that social data:

  1. The graph: who I know, who my Facebook friends are, who I follow on Twitter, etc.
  2. The management of OAuth token interactions so users could sign in to our site by using Facebook or Twitter connect.
  3. Token storage and interactions with those platforms

If you want to have scaling problems long before you ever have a business, slurp in everyone else’s social graph -- we had terabytes of data in Mongo on EC2 before it had SSDs -- everything about it was awful. Inside those terabytes of data was about 200K of authentication tokens, which were required to allow someone to access our site. The service was collapsing all the time and when it was broken, users couldn’t get into our site.

That was not a great system. We had managed to build a front-end monolith and behind it we had a monolithic service. We had two monoliths, which is about the only thing worse than having one monolith.

But it gets better! On the site users were able to like, sell, buy or view products. Those things were not external data so they were stored in the main monolith. Whenever users wanted to understand if someone cared about something, they had to merge datasets from the monolith and the monolithic service. Two massive datasets being merged in a Rails web server. This was a complete disaster.

I think everyone is leaving this party so I should too...

What did we do at this point? We merged everything back into the monolith, which is a sure sign that we should not have been doing services so early. If it’s bad to go from a monolith to services, it’s a lot worse to go from a bunch of services to a monolith and then back to the right services.

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.

Rob Zuber, CircleCI
Rob Zuber, CircleCI

In conclusion, right now is a great time to be thinking about architecture, but it’s also important to do it in a way that is incremental and allows you to test ideas and validate them rather than trying to turn on a dime and build totally differently. That’s going to fail and turn into a nine month project that finishes with you telling your VP of engineering that, while you learned a lot, in the end the team decided not to ship it. That’s not what you want to do. You want to be providing value and impact to your customers and business through planned and well-thought out processes.

Rob Zuber is CTO of CircleCI, a continuous integration and continuous delivery platform.

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Commentary
Study Proposes 5 Primary Traits of Innovation Leaders
Joao-Pierre S. Ruth, Senior Writer,  11/8/2019
Slideshows
Top-Paying U.S. Cities for Data Scientists and Data Analysts
Cynthia Harvey, Freelance Journalist, InformationWeek,  11/5/2019
Slideshows
10 Strategic Technology Trends for 2020
Jessica Davis, Senior Editor, Enterprise Apps,  11/1/2019
White Papers
Register for InformationWeek Newsletters
State of the Cloud
State of the Cloud
Cloud has drastically changed how IT organizations consume and deploy services in the digital age. This research report will delve into public, private and hybrid cloud adoption trends, with a special focus on infrastructure as a service and its role in the enterprise. Find out the challenges organizations are experiencing, and the technologies and strategies they are using to manage and mitigate those challenges today.
Video
Current Issue
Getting Started With Emerging Technologies
Looking to help your enterprise IT team ease the stress of putting new/emerging technologies such as AI, machine learning and IoT to work for their organizations? There are a few ways to get off on the right foot. In this report we share some expert advice on how to approach some of these seemingly daunting tech challenges.
Slideshows
Flash Poll