So you’re sitting on hundreds of thousands of lines of legacy C++. Oh, who are we trying to kid? It’s millions of lines of Vectran, a short-lived Fortran variant created by IBM in the ’70s. But hey, if it ain’t broke, right?
To read this article in full or to leave a comment, please click here
(Insider Story)
InfoWorld Cloud Computing
Developers are finding a new way to create apps and programs – here’s a quick look at how microservices work, and what it means for IT shops and their development operations.
InfoWorld Cloud Computing
Sinclair is CEO and cofounder of Apprenda, a leader in enterprise Platform as a Service.
It seems like every conversation related to cloud-native software projects these days involves microservices. During those conversations, someone inevitably draws a comparison with service-oriented architecture (SOA) or hesitantly asks the question, “Aren’t microservices just SOA?” While it might not seem important on first glance, this is actually a pressing question that gets little attention.
Usually this question is either outright dismissed in the negative or unquestionably accepted in the affirmative. As an exercise in more deeply answering the question, let’s spend time a little time understanding SOA and microservices independently and then comparing.
In the early 2000s, service-orientation became a popular design principle. Driven by backlash against highly coupled, binary-oriented systems, service-orientation promised significant increases in flexibility and compatibility. Microsoft’s Don Box was one of the first to truly spell out the guiding principles of SOA, captured in four simple tenets:
1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not class
4. Service compatibility is based on policy
By adopting a service-oriented architecture that adhered to these tenets, one could unlock the value in SOA. Very quickly the world’s top software vendors capitalized on the opportunity and began building platforms and technologies to support the concept.
In fact, the SOA movement became almost entirely a vendor-driven paradigm. Vendors scrambled to build middleware to allow developers to build SOA components that could be delivered and managed in the context of those four tenets. That middleware, in many instances, became bloated. Moreover, industry specifications that defined things like SOA schemas and policy management also became bloated. This bloat resulted in heavyweight components and a backlash by developers who viewed SOA as a cumbersome, unproductive model.
In the mid-2000s, cloud infrastructure started gaining steam. Developers were able to quickly standup compute and storage needs and install and configure new applications to use that infrastructure. Additionally, applications continued tackling new levels of scale, requiring distributed architectures to properly handle that scale.
Distribution of components forced segregation of application logic based on functionality. That is, break up an application into smaller components where each component was responsible for specific functions in the app.
This ability to instantaneously call-up infrastructure coupled with the propensity for developers to use distributed architectures prompted individuals to think about formalizing thoughts for a framework. Microservices became a concept that embodied much of this and more.
It would seem that the backstory for microservices satisfies tenets 1 through 3 (although 3 is a bit more relaxed in microservices since a REST API wouldn’t typically be considered a strict contract), making microservices very similar to SOA. So how is that different than SOA?
Microservices, as originally conceptualized by Martin Fowler and James Lewis, extend expectations beyond how an application is partitioned. Microservices as a pattern establish two other important tenets:
5. Communication across components is lightweight
6. Components are independently deployable
These seemingly small additions to the criteria defining microservices have a drastic impact, creating a stark difference between the microservices and SOA.
Tenet 5 implies that complex communications buses should not be used in a microservices architecture. Something like an enterprise service bus (ESB) under the hood would create a large, implicit system dependency that would, by proxy, create a monolith of sorts since all the microservices would have one common, massive dependency influencing the functional end state.
Tenet 6 means that deployment monoliths are not allowed (which is something that was common in SOA). Each service should carry its isolation all the way up the SDLC to at least deployment. These two tenets ensure that services remain independent enough that agile, parallel development are not only possible, but almost required. While SOA meant that logic was divided into explicitly bounded components for the same application, microservices’ independent deployability means that the components need to be for the same application at all, and may each be their own independent application.
SOA set the tone for the fundamental architectural concepts embedded in modern microservices, but didn’t go far enough to create a powerful model that would solve the problems associated with bloat and speed of development. Microservices principles have a huge impact in how we think about the software development process and are not just a prescription for the architectural outcome. Thus, microservices can create a better outcome than its SOA predecessor.
Are microservices just SOA redux? originally published by Gigaom, © copyright 2015.
Related research and analysis from Gigaom Research:
Subscriber content. Sign up for a free trial.
Sinclair is CEO and cofounder of Apprenda, a leader in enterprise Platform as a Service.
With all of the talk these days about microservices and distributed applications, monolithic applications have become the scourge of cloud systems design. Normally, when a new technical trend emerges to replace a previous one, it is due (at least in part) to evolved thinking. The odd thing with monolithic application architecture, however, is that nobody ever proposed it as a good idea in the first place.
The idea of loosely coupled services with clear boundaries has been around for decades in software engineering. So, how did we end up with so many apps “designed” as monoliths? In a word – convenience.
The fact is, in many use cases, monolithic architectures come with some non-trivial and durable benefits that we can’t simply discount because it doesn’t adhere to a modern pattern. Conversely, microservices can introduce significant complexity to application delivery that isn’t always necessary.
As a fan of microservices, I fear enterprises are blindly charging forward and could be left disappointed with a microservices-based strategy if the technology is not appropriately applied. The point of this post isn’t to pour FUD onto microservices. It’s about understanding tradeoffs and deliberately selecting microservices based on their benefits rather than technical hype.
Generally speaking, monolithic applications are easier to debug and test when compared to their microservices counterparts. Once you start hopping across process, machine, and networking boundaries, you introduce many hundreds of new variables and opportunities for things to go wrong – many of which are out of the developer’s control.
Also, the looser the dependency between components, the harder it is to determine when compatibility or interface contracts are broken. You won’t know something has gone wrong until well into runtime.
If your shiny new mobile app is taking several seconds to load each screen because it’s making 30 API calls to 30 different microservices, your users aren’t going to congratulate you on this technical achievement. Sure, you can add some clever caching and request collapsing, but that’s a lot of additional complexity you just bought yourself as a developer.
If you’re talking about a complicated application being used by hundreds of thousands or millions of users, this additional complexity may well be worth the benefits of a microservices architecture. But, most enterprise line-of-business applications don’t approach anything near that scale.
Fortune 500 enterprises I work with struggle with managing the relatively coarse-grained application security IT departments use today. If you’re going to break up your application into lots of tiny services, you’re going to have to manage the service-to-service entitlements that accompany this plan. While managing “many as one” has time tested benefits, it’s also contrary to the motivation behind microservices.
Microservices have a higher up-front design cost and can involve complicated political conversations across team boundaries. It can be tricky to explain why your new “pro-agile” architecture is going to take weeks of planning for every project to get off the ground. There’s also a very real risk of “over-architecting” these types of distributed solutions.
Having said all of this, microservices can absolutely deliver significant benefits. If you’re building a complicated application and/or work across multiple development teams operating in parallel and iterating often, microservices make a ton of sense.
In fact, in these types of situations, monolithic applications simply serve as repositories of technical debt that ultimately becomes crippling. There is a clear tipping point here where each of the advantages of monolithic applications I described earlier become liabilities. They become too large to debug without understanding how everything fits together, they don’t scale, and your security model isn’t granular enough to expose segments of functionality.
One way to help reduce and in some cases even eliminate the technical “tax” associated with microservices is to pair them with an enterprise Platform as a Service (PaaS). A proper enterprise PaaS is designed to stitch together distributed services and takes deployment, performance, security, integration, and operational concerns off the developer and operators’ plates.
Why monolithic apps are often better than microservices originally published by Gigaom, © copyright 2015.
Related research and analysis from Gigaom Research:
Subscriber content. Sign up for a free trial.