This article is a preface to the free white paper, Standing on the Shoulders of Giants: Supercharging Your Microservices With NetflixOSS and Spring Cloud. In it, Pivotal’s Senior Director of Product Richard Seroter takes a look at the architectural challenges Netflix faced, what they’ve released as open source software, why this software matters to you, and how Pivotal makes it easy to consume Netflix software as part of Spring Cloud.
Back in 1869 when Washington Roebling started work on the Brooklyn Bridge, there wasn’t a tradition of collaboration among fellow bridge builders. Engineers were encouraged to mind their own business and rarely offered up insight that would be deemed “valuable” to rivals. This meant that information about a mysterious illness crippling workers building a bridge in St. Louis was not socialized with the professional community. If Roebling had access to this information, or the findings from Europe about this affliction later labeled “the bends,” the lives of many men would have been spared.
What does this have to do with microservices? As it turns out, a lot. We’re now in a period of unprecedented openness and collaboration among technical colleagues. Instead of building systems made up of proprietary technology and closely-guarded local knowledge, companies are constructing modern microservices with the help of open source software and patterns evangelized by forward-thinking members of the community. This sharing of assets helps developers build more reliable software, faster. And almost no one shares their software assets quite like Netflix.
Instead of building systems made up of proprietary technology and closely-guarded local knowledge, companies are constructing modern microservices with the help of open source software and patterns evangelized by forward-thinking members of the community.
Netflix is a media giant, with over 80 million global customers who watch more than 125 million hours of streaming content everyday. During primetime hours, Netflix consumption constitutes 35% of all Internet traffic in North America. In 2008, Netflix started their journey to the cloud and microservices for three reasons: availability, scale, and speed. As a 24x7 service, Netflix needs to be “always on” and their monolithic code base made troubleshooting problems difficult. Back then, a single missing semicolon took the entire Netflix site down for hours! The company also faced scaling challenges that were hard to address within a single monolithic application. As Netflix added more types of user interfaces to their service and expanded into more geographies, they couldn’t easily scale individual parts of their application. It was all or nothing.
Finally, Netflix needed to optimize for speed. In a competitive market, companies like Netflix have to help teams deliver more software, faster, and that’s not easily achievable when everyone steps all over themselves in a single monolithic system.
Netflix is a software-driven business, so their engineers constructed an impressive array of software that builds upon foundational components from Amazon Web Services, their chosen cloud provider. As an early adopter of microservices and highly-resilient cloud systems, Netflix solved a number of these complex problems that most companies are just starting to face. They’ve shared these hard-fought lessons in the form of open source software that anyone can use to build cloud- scale systems.
Microservices: Opportunities and Challenges
With a microservices architecture, you have many individual components, each associated with a specific responsibility, loosely coupled to each other, continuously delivered by independent teams through automation. Let’s unpack that sentence, and compare these attributes to those of a monolithic software solution.
… many individual components …
Traditional business systems are often monolithic in nature. All of the business logic, user experience, and integration interfaces are part of a single code-base or software installation. It’s often fairly self-contained, but not modular in a way that supports component upgrades. Conversely, a microservices architecture has lots of little pieces that may be dedicated to a given application, or shared by many systems. “Micro” is meant to refer to the scope of the service, so don’t get caught up in “physical size” or “lines-of-code” as meaningful attributes.
… each associated with a specific responsibility …
In his O’Reilly book titled Migrating to Cloud-Native Application Architectures, Matt Stine says that it’s about creating:
“… independently deployable services that do ‘one thing well.’ That one thing usually represents a business capability, or the smallest ‘atomic’ unit of a service that delivers business value.”
A hallmark of microservices is building discrete services that don’t encroach on the domain of others. As a reference, the principles of “domain driven design” help teams successfully define their boundaries. Because services should “own” whatever they need to deliver a given business capability, experts recommend that microservices have their own data store. This concept requires a major shift in how we’ve traditionally design software, but offers a compelling approach to those have spent years building or maintaining dense, tangled systems.
… loosely coupled to each other …
One of the major challenges in a monolithic business system is the interconnectedness of all the components. Are you changing the database structure, swapping out a web server, or altering some business logic? Often this requires an update to numerous components because of the uncomfortable closeness of all the pieces. As a result, teams shy away from making (necessary) updates because of the many ways that things could go wrong.
Conversely, microservices encourage loose coupling. Services interact with each other through contracts or messaging buses, and have zero knowledge about the implementation details. The owner of a particular microservice can responsibly iterate on the service without fear of shattering a fragile relationship with its ecosystem. Thus, encouraging teams to make frequent changes.
… continuously delivered by independent teams ….
If one believes in Conway’s Law — the observation that systems reflect the organizational communication paths of those who build them — then a transition to microservices must be accompanied by a corresponding change in the team. The same project teams and line-of-business hierarchies that created a data center full of monolithic business systems cannot successfully create a microservices architecture.
Instead, microservices often bring about a major change in team structure and tooling. If the goal is to continuously deliver business logic in the form of microservices, then software teams need the autonomy and directive to build and deploy focused services all on their own. This means that short-lived project teams give way to long-lived, independent product teams. These teams don’t file tickets to do deployments; they directly push to production early and often. The team makeup consists of all the skills needed to design, build, and deploy the service. Such teams have the personnel, permission, and technology needed to iterate constantly and get the results of each iteration into production immediately.
The same project teams and line-of-business hierarchies that created a data center full of monolithic business systems cannot successfully create a microservices architecture.
… through automation.
Pivotal’s Casey West says that microservices are about “automating the path to production.” It’s virtually impossible to ship software constantly if the delivery pipeline is manual, as it has historically been with monolithic software. Automation is a core part of the microservices experience, enabled via continuous integration, continuous delivery, and continuous deployment. Continuous integration refers to the practice of developers merging all their code multiple times per day. Instead of slogging through the “integration testing” phase of a project where countless unforeseen mismatches occur between code modules, continuous integration ensures that issues bubble up faster. There are a lot of logistics required to constantly execute tests, so modern teams rely on event-driven automation to retrieve source code, stand up infrastructure, and execute tests.
If all the tests pass, code could be considered production ready. Continuous delivery happens when code is packaged and capable of being deployed to production. Capable being the key word here. There could be many reasons why the pipeline is completely automated, but code is purposely gated before actually getting deployed, usually related to business timing. Continuous deployment goes one step further and involves every change automatically moving to a production environment.
All of these techniques require a careful assessment of current deployment procedures, and a ruthless focus on eliminating waste and automating manual steps. The result? Repeatable, timely deployments that greatly reduce the amount of time needed to get valuable software into the hands of your customers.
In this paper, we take a look at the architectural challenges Netflix faced, what they’ve released as open source software, why this software matters to you, and how Pivotal makes it easy to consume Netflix software as part of Spring Cloud. To learn more, download the free white paper here.
Richard Seroter is Senior Director of Product for Pivotal, a nine-time Microsoft MVP for cloud/integration, an instructor for developer-centric training company Pluralsight, the lead InfoQ.com editor for cloud computing, and author of multiple books on application integration strategies. As Senior Director of Product at Pivotal, Richard leads the marketing team for Pivotal Cloud Foundry and Spring, and helps describe the value of continuously delivering software to a cloud native platform. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
