- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Professional Services
- Commercial Support
- Code Recipes
John Wetherill, August 14, 2014
Not long ago, the main application behind Netflix.com was delivered as a single war file. Imagine the process, complexity, and cost involved in delivering a simple new feature to this behemoth application. Tickets were submitted, multiple teams were engaged, VP approval was required, hours/days of time elapsed, exhaustive test-suites were run, complex deployment procedures were invoked. It's amazing they were able to get anything out the door.
Not so anymore. Last week I had the pleasure of attending a meetup hosted at the San Jose Cisco campus where ex-Netflix architect Adrian Cockroft and others described the microservices architecture now in place at Netflix. This architecture allows them to be much more fluid and flexible with their software delivery, and ultimately enables them to be the disruptive company that they clearly are.
This blog is divided into two parts. Part I introduces microservices and captures some of the important points made at this meetup, while Part II will cover the many ways that Platform as a Service enables the effective use of a microservices architecture, including a discussion of suggested practices to follow to optimize their use.
Microservices not Monoliths
Adrian describes microservices as "fine grained SOA." In a microservices architecture, an application is comprised of a number of small, independent composable services that interact by way of an external published protocol, such as REST, or a messaging service.
Each service is focused on an individual targeted business capability, and thus its scope is minimized. For functionality out of scope, the microservice calls out to other microservices via the published protocol.
Each microservice should not depend on other microservices: It can be deployed, scaled, and managed independently with no effect on other microservices.
The Old Monolithic Way
Contrast this with a traditional monolithic application, such as the familiar 3-tier enterprise application with persistence layer, user interface layer, and a middle-tier, which is commonly a server-side application encompassing the business logic and orchestrating the entire flow.
Each tier is usually delivered as a single monolithic unit. Any changes to any part of this tier require the entire thing to be redeployed. A large product team consisting of IT, development, QA, and deployment is responsible for building, maintaining, testing, and deploying such an application.
This style of building apps has been with us for decades, and has mostly served us well, but it's showing its age. While there's isolation between the tiers, the individual pieces that make up each tier are tightly coupled with complex interdependencies, resulting in long, complex, and costly change cycles. In a nutshell, it's not agile.
A microservices architecture brings some significant advantages:
Small Focused Teams
Instead of a large, monolithic, complex team devoted to a large, monolithic, complex application, microservices allow for small, independent, targeted teams that focus on a specific microservice. The team may be as small as one, and its size certainly shouldn't violate the Two Pizza Rule.
Use the Right Tool for the Job
Similarly, there's no reason to standardize on a single persistence layer across an entire application. Some microservices might best be served by Redis, others by Oracle. It’s up to the targeted development team to choose the best solution.
Each microservice can be updated independently, no longer requiring the entire application to be redeployed.
Netflix and Microservices
While revamping their entire architecture, and entire organization, to use microservices, Netflix learned some valuable lessons.
Software development is the long pole in enterprise success. Rapid software delivery is the most important factor for success, and thus, effort spent in streamlining this is effort well spent. Microservices drastically improve the time required to push out a new update, allowing a much more agile development process. Ultimately, the goal was to remove or reduce the friction in the software delivery process.
Trusting developers, and promoting a culture of freedom with responsibility not only reduces software delivery times and increases success rates, but also has the side effect of improving workplace culture and employee retention. With small teams, each focused on an individual microservice, Netflix enables developers to push code to production, instead of getting mired in a complex deployment process involving several teams.
Many organizations consist of specialized silo teams (UI, database, API, etc) where costly handoffs and intercommunication are required to coordinate all the pieces of application construction. These handoffs cause overhead, and the need for them should be eliminated.
DevOps Mentality a Must
With microservices, the old IT mindset just doesn't work. Each microservice is different, and unique skillsets are required to understand, manage, and deploy them. A centralized IT department cannot possibly cover the wide array of technologies spanning all microservices. Instead a DevOps structure, where each team is responsible for the management of the corresponding microservice, is essential.
Self Service Makes Previously Impossible Things Instant
Enable developers to concoct systems of their choosing with minimal or no interaction from IT, management, VPs, hardware or other groups. "Self Service" is one of the major capabilities offered by the cloud and there's every reason to take advantage of this.
One thing that self service enables is experimentation. Developers can ask "What would happen if we fired up a bunch of systems in Brazil" or "What are the performance characteristics of creating a large-scale global cluster with 200TB of SSD across 6 data centers?"
These questions can be answered in minutes or hours, in contrast with the old "data center" way, where creating a large-scale global cluster would takes dozens of service tickets, months of effort, gazillions of dollars, and large teams of people. For experimental questions like those above, this just never happens.
Now, IT can be considered as a cloud API available to the developer on-demand 24x7, instead of a complex, process-mired division hidden behind obscure process.
Process is Scar Tissue
Speaking of which, process is usually based on old and legacy ways of doing things. As a result, it rarely adapts to new requirements, is often complex and burdensome, and brings with it all sorts of baggage like training and documentation overhead. To an organization delivering software, process is "scar tissue" and should be removed.
Invert Conway's Law
Many enterprises these days build monolithic software, which is no surprise given that this is what they're good at. Their team structure is monolithic, their whole way of thinking is monolithic. It's what they do.
This is a direct manifestation of Conway's Law which states that "the interface structure of a software system will reflect the social structure of the organization(s) that produced it." So if we start off with a company that's complex, costly to run, fragile, inflexible, mired-in-process, and bureaucratic, guest what? We'll end up with software that has the same characteristics.
Obviously software must be lean, flexible, low-cost, and responsive.
Adrian suggested that to achieve this we need to invert Conway's law. Instead of building software that resembles our existing organizations, we should figure out how we want our software to look, then build the organization around that. Or reorganize it if it's already in place.
This obviously goes against the grain of how most enterprises operate. Legacy teams, legacy ideas, old patterns and ways of doing things: these are very difficult to change. The end result is that our software systems end up being costly, complex, fragile, inflexible, process-ridden, and bureaucratic. Just like our organizations.
Netflix was able to invert this process to great success.
Immutable Code Service Patterns
This is a powerful technique employed by NetFlix and enabled by the use of independent microservices. When deploying a new feature, enhancing or fixing an existing capability, or deploying an experimental line of code, the previous code remains available and accessible. New code is deployed alongside the old code, with mechanisms in place to instantly route to one or another version.
This is essentially A/B testing at a massive scale. Individual features, services, webpages, widgets, and apps are versioned with associated "feature flags." This allows developers to deploy experimental code which can be made available to a small subset of users. The first users to see the new feature would be developers, test engineers, and other product team members. Once these folks are happy that a feature is functioning correctly, a cohort of selected users (early adopters, partners, or users requesting specific features) can be included. Finally, the new feature can rolled out to all users, by simply toggling flags and updating user lists.
Importantly, the old code is not replaced, but remains part of the system, and is kept running. If, as is often the case, the widespread introduction of the new feature results in unforeseen consequences, the feature flag can be toggled off, and the old version is instantly used instead.
Such a strategy requires sophisticated mechanisms for managing the routing and versioning based on the feature flags and this isn't yet generally available in today's PaaS offerings. Thus some investment in home-built tooling is required. NetFlix has obviously made this investment, to great success.
The Microservices meetup was rich with content, and here I've barely scratched the surface of the helpful information that was provided.
Title image courtesy of Shadowgate on Flickr under Creative Commons License.
If you would like to learn more about microservices and PaaS, watch the recording of the webinar I did with Phil Whelan called Microservices Not Monoliths: Using PaaS to Enable a Microservices Architecture
This is Part IV of the ever-expanding "Microservices and PaaS" blog series covering the rapidly evolving use of microservices in modern cloud software projects. Parts I and II introduced microservices concepts and discussed patterns and practices being spearheaded by microservices pioneers, notably Netflix, who were represented at a recent microservices meetup that was the genesis of this series.
The other day I paid a king's ransom for a small upcoming ebook called “Building Microservices” by Sam Newman. Overall it's an interesting read, chock-full of information on microservices, how to adopt and use them, architecture details, and how they're evolving. But there's a glaring omission: while the first chapter covers multiple benefits provided by microservices, explaining their superiority over other approaches such as monolithic apps, SOA, modules, and shared libraries, it completely neglects to mention any downsides, challenges, pitfalls, or disadvantages to adopting a microservices architecture. This is a dangerous omission in my opinion, and has prompted me to dedicate the third post in this microseries on microservices to this very topic: the Challenges of Microservices.
This is a continuation of the Microservices and PaaS - Part I blog post I wrote last week, which was an attempt to distil the wealth of information presented at the microservices meetup hosted by Cisco, with Adrian Cockcroft and others presenting. Part I provided a brief background on microservices, with a summary of some lessons learned by microservices pioneers. In this installment I will cover a number of practices related to microservices that were discussed during the meetup.
Subscribe to ActiveState Blogs by Email
Share this post: