Welcome!

Government Cloud Authors: Yeshim Deniz, Elizabeth White, Pat Romanski, Dana Gardner, Liz McMillan

Related Topics: Microservices Expo, @CloudExpo, @DevOpsSummit

Microservices Expo: Blog Post

Are Microservices ‘SOA Done Right’? By @TheEbizWizard | @DevOpsSummit #DevOps #Microservices

Microservices architecture will never be SOA done right unless it means building hypermedia systems of microservices.

Given my years at ZapThink, fighting to help architects understand what Service-Oriented Architecture really was and how to get it right, it’s no surprise that many people ask me this question.

If you took my SOA course, you can probably guess my answer: it depends.

Even to this day we don’t have a universally accepted definition of SOA. But even if we did, we’d also have to figure out what “SOA done wrong” means, in order to contrast microservices with it.

However, the question “Are Microservices ‘SOA Done Right’?” itself is a mix of apples and, well not oranges – more like confusion between apples and best practices for running an orchard.

What we really mean to ask is whether microservices architecture is SOA done right. But then, of course, we’d have to figure out what microservices architecture was. And if you think defining SOA is difficult, pinning down microservices architecture is unquestionably frying pan into fire time.

The last thing I want to do, however, is make this Cortex into a discussion of the definitions of terms. True, defining terms is what architects love to do best – even though they never end up agreeing. It’s no wonder that the collective term for these folks is an argument of architects.

SOA Done Wrong

In my Bloomberg Agile Architecture Certification course I paint the difference between what I like to call first generation and second generation SOA. The first generation centered on the role of the ESB, and sported Web Services as the primary type of service.

It might well be argued that this middleware-heavy, XML-laden approach to SOA was SOA done wrong, and to be sure, many times it was – but then again, on occasion a particularly hardworking and indubitably masochistic architecture team actually got this stuff to work.

Second-generation SOA is REST-based, favoring lighter weight approaches to moving messages around than the heavyweight ESBs that gave SOA a bad rep. Note, however, that the rise of REST-based SOA predates the microservices wave – so only through some convoluted revisionism might we call this approach microservices architecture.

We might therefore also ask whether this second generation, REST-based SOA was SOA done wrong as well. Once again, the answer is sometimes yes, sometimes no.

RESTful interfaces clearly cleaned up a lot of the mess that Web Services left behind. But implementing properly abstracted, governed service interfaces in the absence of traditional middleware often proved to be surprisingly difficult.

ESBs might be SOA crutches to be sure, but don’t forget, the alternative to crutches is often falling on your face.

Reinventing the Service

Fortunately, the microservices story isn’t about ESBs. It’s about services. Starting from the earliest days of first-generation SOA and running throughout SOA’s RESTful days, the word service meant a contracted software interface. In other words, a service abstracted the underlying software rather than being software itself.

Microservices, in contrast, rethink the notion of service altogether. No longer is a service a contracted software interface at all. Instead, a microservice is a unit of execution.

I like to define a microservice as a parsimonious, cohesive unit of execution. By unit of execution I mean that microservices contain everything from the operating system, platform, framework, runtime, and dependencies, packaged together. And naturally, microservices are fully encapsulated, supporting interactions entirely through their (usually RESTful) APIs.

See my recent BrainBlog post for a deeper discussion of microservices (in particular, what I mean by parsimonious and cohesive) – as well as some insight into how microservices architecture is supposed to work. But even with my thought-provoking connected car scenario from that post, we still have the questions of the day: is such a microservices architecture SOA? And if so, is it SOA done right?

Microservices typically have RESTful interfaces, and we’re likely to have sufficient metadata that will qualify as a service contract. As a result, we end up with the awkward namespace collision that microservices expose services – but aren’t services themselves in the sense of service as a contracted interface.

But that distinction is neither here nor there. Maybe it’s time to update our notion of service to include units of execution. Especially if we’re using containers.

Microservice Architecture as Container-Oriented Architecture

It’s no coincidence, of course, that the definition of microservice makes them particularly well-suited for containers. And while you could certainly implement microservices without containers and vice-versa, there’s no question that the cool kids are combining these two approaches.

If you’ve been following the activity in the container world, you’ll have noticed that quite a bit of thought has been going into the question as to what container-oriented architecture best practices might be. Docker in particular is blazing this trail – but the work isn’t nearly ready for prime time.

Even in its formative state, however, container-oriented architecture doesn’t look much like SOA – done right or not. And yet, the questions of whether microservice architecture and container-oriented architecture will end up being the same thing – or even whether they should be the same thing – still remain to be answered.

Regardless of which side you fall on these questions, there are aspects of container-oriented architecture that weren’t part of the SOA story – or at least, the first-generation SOA story: cloud architecture best practices.

What cloud computing brought to the SOA table are the principles of horizontal scalability and elasticity, automated recovery from failure, eventually consistent data (or more precisely, tunable data consistency), and a handful of other now-familiar architectural principles.

And in fact, these cloud principles complement next-generation SOA, just as they form the basis of container-oriented architecture. And since microservices are container-friendly by design, our argument of architects might argue that microservices architecture is SOA plus cloud architecture done right.

Service Composition: The Missing Piece of the Puzzle

One important aspect of the SOA story is missing from this discussion, however: service composition. Central to first-generation SOA was the goal of composing services in order to implement business processes – a goal that led to the BPEL standard for Web Service composition, a debacle that to this day remains notorious for its abject failure.

Bottom line: if you want to talk about SOA done wrong, look no further than how service compositions failed to implement business processes.

As we moved to second generation, REST-based SOA, the service composition story takes an interesting turn, as REST does have an angle here: hypermedia. Roy Fielding’s original vision for REST was as an architectural style for building hypermedia systems – and lo and behold, what is a hypermedia system but an executable composition of RESTful services?

Still with me? No? Well, you’re not alone. Few people understood all this gobbledygook about hypermedia, in particular, REST’s hypermedia constraint – you know, hypermedia as the engine of application state? – so they decided to punt on the whole shebang. REST in practice became little more than an API style, which it remains to this day.

So now we’re discussing microservices architecture – which means we have to ask how best to compose microservices. The jury is still out on this question, but there’s one thing I can say about microservice composition: it must be parsimonious and it must be cohesive.

And given that microservices have RESTful interfaces, the architectural approach for composing them that is both parsimonious and cohesive is to treat microservice compositions as hypermedia systems.

Mark my words: microservices architecture will never be SOA done right unless it means building hypermedia systems of microservices. You heard it here first, folks.

The Intellyx Take: SOA Done Right

SOA has always been a rather loose collection of architectural best practices. And you know what makes a practice a best practice? You try a bunch of things, and the one that sucks the least is the best practice. At least, until a better one comes along.

Now that SOA has a few decades under its belt, the loose collection of best practices we call SOA continues to mature, as new practices gradually supplant earlier contenders. In this bucket we’re now adding various microservices best practices and container best practices – both unquestionably in their “whatever sucks the least” phase.

And we’ve also added cloud best practices and REST best practices to the mix – including the hypermedia best practices that have always been the raison d’être of REST. And to be sure, we have our tried and true SOA practices – not the ones that led us to failure, but the practices that through years of hard work and trial and error finally led us to successful implementations that supported our business agility drivers.

SOA done right, therefore, isn’t a fixed goal to aspire to. It’s a journey of architectural discovery, as we piece together the hard-fought lessons of enterprise system deployments, one practice at a time. And as long as we learn the lessons of the past, we will continue to make progress toward our ultimate business goals – sucking less as we go.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. At the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Aussie~mobs.

 

More Stories By Jason Bloomberg

Jason Bloomberg is a leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018 and #15 on Jax’s list of top DevOps influencers for 2017, the only person to appear on both lists.

As founder and president of Agile Digital Transformation analyst firm Intellyx, he advises, writes, and speaks on a diverse set of topics, including digital transformation, artificial intelligence, cloud computing, devops, big data/analytics, cybersecurity, blockchain/bitcoin/cryptocurrency, no-code/low-code platforms and tools, organizational transformation, internet of things, enterprise architecture, SD-WAN/SDX, mainframes, hybrid IT, and legacy transformation, among other topics.

Mr. Bloomberg’s articles in Forbes are often viewed by more than 100,000 readers. During his career, he has published over 1,200 articles (over 200 for Forbes alone), spoken at over 400 conferences and webinars, and he has been quoted in the press and blogosphere over 2,000 times.

Mr. Bloomberg is the author or coauthor of four books: The Agile Architecture Revolution (Wiley, 2013), Service Orient or Be Doomed! How Service Orientation Will Change Your Business (Wiley, 2006), XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996). His next book, Agile Digital Transformation, is due within the next year.

At SOA-focused industry analyst firm ZapThink from 2001 to 2013, Mr. Bloomberg created and delivered the Licensed ZapThink Architect (LZA) Service-Oriented Architecture (SOA) course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, which was acquired by Dovel Technologies in 2011.

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting), and several software and web development positions.

IoT & Smart Cities Stories
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.