Small is Beautiful

A company intending to move fast and stay innovative in a highly competitive market requires an architecture that can scale.

If you are part of a startup, you have a unique opportunity to lay the groundwork for a development model that enables fast development and high scalability. This article is about how using the Microservice Architecture can help.

Microservices Are Not Revolutionary (anymore)

Amazon pioneered the microservice architecture in 2001. Since then major companies like Netflix, Ebay, Groupon, PayPal, Spotify have followed. It is a proven development model for HTTP based  applications. With the growing availability of inexpensive cloud hosting services, it is an architecture that is accessible to anyone.

Benefits

No More Major Releases

Major release dates are common for monolith applications with waterfall management. With microserices, they disappear.

Microservices can be versioned and deployed  independently without compromising the integrity of the overall application. Release dates are just microservice deployments and they happen frequently. There are no more service updates required either.

Amazon does over 50,000 deployments a year.

Decouple Concerns

Take big problems and break them down into smaller components, defining the contracts between the components (which an API is).

Test the components in isolation and most importantly deploy and run them independently.

Mix them up with third-party services however needed to provide the needed functionality.

Deploy as frequently as needed knowing that you won’t break anything else.

Two Pizza Teams 

Amazon calls them “two-pizza teams” meaning you can feed them with just two pizzas. These are fully motivated full-stack teams that ensure the entire end-to-end lifecycle operates efficiently for their service. They do not need to waste time on synchronization hell within the organization. Their missions do not overlap other teams missions.

Microservice architecture gives developers the freedom to independently develop and deploy their services a their own pace.

Deployment Containers

Docker and other container technologies are enablers of microservice architecture.

Containers are designed to be pared down to the minimal viable pieces needed to run whatever the one thing the container is designed to do, rather than packing multiple functions into the same machine.

The ease of development that containers provide make possible rapid development and testing. Applications are smaller, so they deploy really fast.

Platform Choice

Developers have the freedom to independently develop and deploy services using whatever tools are best. Service A can for example use MongoDB and framework X written in Java while Service B can use something completely different like MySQL and framework Y written in Ruby on Rails.

Code for different services can be written in different languages and deployed on different platforms. HR recruiters are not forced to find people with specific skills matching a monolithic application specs.

Testability

It’s way easier to test as the test as there is much less to test. There are no issues with code changes breaking tests in distant parts of the system.  Developers can test services locally without having to deploy them to a test environment.

No more need to run hours of tests that often fail for no apparent reason sending whole departments into a scramble.

 

Resilience

Microservices are less susceptible to large failures: big services fail big, small services fail small.  Large failures trigger anger, fear and a loss of confidence for customers and are the leading cause of customer attrition.

The Microservices architecture permits services to go down without the users even noticing it. The system is built assuming that services can fail all the time. Individual services are not doing too much, so they can’t take down the whole system.

 

Best for Cloud Hosting

Components can be spread across multiple servers/data centers. Fast networks with multi core machines are cheaper than ever.

In HBO’s Silicon Valley the main characters continually struggle with massive hosting costs. Always good for a laugh, but it is real an issue for many Sass companies. These costs can make or break profit margins.  Microservices help in decentralizing hosting and allowing the best options for specific microservice requirements.   You use the best option for each service rather than lumping them all onto the same server.

 

A New Hope for Old Business

One aspect of development that older companies tend to get bogged down with is technical debt related to monolithic applications. These applications largely consist of legacy code. Adding new features if a complicated and often risky.  Caution is the governing rule and change does not come easily, so process is bogged down with “safe” practices. Basically everything is done to not break any of that code Bob wrote back in 2005 before he retired.

Having a restrictive and cumbersome development process slows the software development lifecycle to a crawl  and stifled attempts to innovate.

Due to the sheer size of many organizations, what may appear as significant changes internally appear from the outside to be glacial movement.

The following case is from a real company. Does it sound familiar?

• The company application has multiple tiers. Each tier has many components tightly coupled together.
• This monolithic beast requires an army of developers, and due to the fact new grads don’t want to use old tech, acquiring new talent is almost impossible.
• “standups” are 10 – 20 people babbling about something irrelevant to 90% of everyone else in the room.
• Developers only typically work on a small piece of the application, but still needed to coordinate anything more than trivial changes with everyone else.
• Development is a game of whack a mole with constant issues of feature changes from one developer breaking features from another.
• Adding new features or making bugfixes involves running hours of tests that “sort” of gave an idea that things are stable, but often fail because, well .. who knows, they just do.
• Code merges are a crap shoot.
• Updating a shared library means sending a request up the chain of command which usually comes back with “this isn’t a good time”.
• Adding a library means everyone else has to upgrade/install it too, and if other developers have problems, they came right back to that first developer.
• When customers ask for a quick fix, it can  take weeks, often months, because everything had to “soak” for a while.
• You are often having “special releases” to fix critical issues.
• There are people with the sole job of merging “safe” code into a massive central repository.
• There is an army of manual testers who pulled developers from their feature work to fix critical bugs, often in code those developers have never touched or even seen before.

If you recognize any of these cases and no longer deal with them, well congratulations! You graduated from lifecycle hell. Your experience at the company probably had one of two outcomes; you left or there was/is a massive re-org.

Fixing the Seemingly Unfixable

Netflix, eBay, Amazon, the UK Government Digital Service, Twitter, PayPal, The Guardian, and many other large-scale websites and applications all converted their architecture from monolithic to microservice.

Most companies using Microservices start with a monolith architecture. A monolithic architecture is very maintainable when the monolith is small enough for a team of 2-10 developers, but beyond that the issues of cross-team dependencies appear.

Big companies with millions of users aside, the vast majority of companies do not have to worry about massive scaling.  Their user base is in the tens of thousands and always will be. Theirs is a paid service for a niche market.  They do have developer and hosting costs, but nothing that requires a revolutionary approach to scaling. They can operate without the use of microservices, but if things have been moving ever more slowly in the app development department, it may be time to take a look.

Adopting a Microservice Architecture

A few years ago, setting up Microservices required a lot of R&D. Nowadays you can packages off GitHub to begin implementing the microservice architecture  in a day.

Due to how easy it is to setup, a startup that wants to be disruptive on their industry is probably best off to start with a microservice architecture. If it turns out it is not really needed in the end,  then just build a massive single service. There is nothing to stop a company from turning a mocroservice into a monolith service.

This really depends on how the company needs to scale in terms of anticipated developers and customers. If your development team is not having problems with the development lifecycle, don’t fix it.  If your developers are always running into blockers where they are relying on other development teams, you’ve got a problem.

Risks

Many Failure Points

One of the biggest risks of micro services is that you introduce many failure points. There are several approaches to solve this such as using the same load balanced clustered hosting provider for all your micro services, but that still gives you one big potential failure point.

A better way (in my opinion anyway) is to use an API gateway that can reverse proxy to backup micro services. This means that is one micro service starts to fail, the API gateway will simply start making call to the second, third, etc.

Monitoring 

They are difficult to monitor since thousands of instances are running at the same time.

Lost Code

Having a distributed architecture means you must always keep tabs on your flock of services. Each service must be well documented with detailed specs for deployment. If you lose key team members on a service, you may end up locked out of that service.

Increased Latency

Microservices are prone to create increased latency: instead of calling a single process, the client is calling a lot of services, and these services are calling other services too, so the latency grows through each of these calls.

Mis·application

In many cases Microservices make no business sense. If you are providing a specialized service that will never need to scale beyond a few thousand users, and your features are not going to be constantly changing, the monolith model makes a lot more sense.

You should take a hard look at your business model and determine what your maximum response times need to be. Look at your data. If your application has complex data rules where a lot of server side processing is required for accurate request results, you will likely be better off using a monolith architecture, at least for the most part. That isn’t to say you can’t use it for certain features such as simple lookup services.

Beyond Buzz

Leave the hype aside and know that from a high level technical point of view microservices architecture is nothing more than a special case of distributed system architecture.

The basic idea is to essentially write software into a collection of small, isolated services, where each service own their data store, can independently be deployed and scaled as needed independently from other services.