Cloud Zone is brought to you in partnership with:

Passionate about technology and startups. Have worked for the BBC in London, Livedoor.com in Japan, Cloudera in San Francisco and MailChannels in Vancouver, Canada. Currently reside in Vancouver where I'm working on building PaaS based on Cloud Foundry, called Stackato. I enjoy writing about technology, especially when it relates to interesting startups. Phil is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website. View Full User Profile

Microservices and PaaS (Part 1)

08.15.2014
| 11557 views |
  • submit to reddit

[This article was written by John Wetherill.]

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.

Microservices Advantages

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

Small independent microservices can be built using the technology best suited for their requirements. No longer does every application component need to be built on a common company-mandated language and framework such as Java/Spring or Ruby on Rails. With microservices, some components can be built with Java, others with Ruby, others with JavaScript/Node. Developers can often be assigned to work with the languages and tools they're familiar with, further increasing productivity and also overall job satisfaction.

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.

Independent Updates

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.

Speed Wins

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.

Empower Developers

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.

Eliminate Handoffs

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.

To Be Continued

The Microservices meetup was rich with content, and here I've barely scratched the surface of the helpful information that was provided.

Part II of this blog will dive further into microservices, with a discussion on the many features in Stackato that support them, as well as details on practices and patterns to follow, or avoid, to best take advantage of them.

- See more at: http://www.activestate.com/blog/2014/08/microservices-and-paas-part-i#sthash.3wuefnLb.dpuf

 

Published at DZone with permission of Phil Whelan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)