“But microservices want to bring you into tomorrow,” says Winterberg. “Microservices add a bit to the category concept, defining a service over all application layers, including the UI. So people already doing SOA may gain a kind of new freedom by adopting microservice ideas.” That freedom includes technology independence and an alternative to aging technologies, because individual services within an application can be gradually swapped out for those based on more-modern technologies, without having to replace the entire application. “Classic SOA is more platform driven, so microservices offer more choices in all dimensions,” says Winterberg.
The picture that emerges is not of microservices as an alternative to SOA, but rather as a way to restore flexibility that may have been lost in SOAs that became too rigid and monolithic.
After 15 years of useful life, CORBA is currently being retired and replaced with Web services. It’s interesting to see that many of the initial performance challenges have appeared again with the switch to the new technology.
It took four years from the strategic decision until the whole organization was fully committed to the plan. This is because it takes a while to fully deploy complex middleware technology in an environment that’s sensitive to performance, stability, and security. The real challenge has been the stamina and governance needed to make this strategic decision pervasive—it took 10 years before everybody accessed the mainframe through the service layer. We debated whether this is unusually slow, but we’re now convinced that this is normal for this kind of organization and application landscape. On the business side, the SOA approach has helped revolutionize user interfaces. Nobody accesses the mainframe through terminal screens anymore. Credit Suisse has built several Internet channels on top of the service layer, from a simple electronic banking application in the beginning to today’s sophisticated mobile banking.
And, the thrilling conclusion:
Looking back over 15 years of enterprise service architecture at Credit Suisse, we’ve learned a few lessons. First, deep architectural changes in large companies take longer than most people think. The reason for this is because most projects are risk-averse and only want to adopt a proven approach. Proving a new approach plus the time lag between design decisions and implementation completion adds up to three to four years. After that, depending on the rollout strategy, it could take several years to fully implement a strategy. Patience and stamina are absolutely necessary for success in this field. If your CIO wants to see results within a quarter, SOA or other enterprise architecture approaches aren’t worth pursuing. Second, when thinking about SOA, technology on an enterprise scale is a nontrivial prerequisite, but it’s the easier part. Orchestrating the entire organization around SOA, providing a proper semantic framework to create a common language across the organization, and implementing the necessary governance processes are the harder parts, in our opinion.
After a thrilling Tweeter-thread on SOA vs. microservices, I thought I’d just playing with some old text, here:
Decomposing an online store like Amazon.com, for example, into its fundamental piece parts yields a set of services – among them: a presentation service to deliver the HTML, a search service to find appropriate items, a shopping cart service and a credit card verification/payment service to check out and purchase items. While many speak of microservices purely in terms of RESTful services, it’s RedMonk’s view that RESTful services are not a prerequisite for delivering a microservices. RESTful services greatly ease the task of exposing services, but a microservices architecture should seek to exploit available services, resources and applications wherever possible. Indeed, many firms have run de facto microservicess using decades old mainframe applications without any assistance from Web technologies. An microservices should seek to exploit available services, resources and applications wherever possible.
You see, I replaced SOA with “microservices” and “Web services” with RESTful services.” Ha. Ha. ..and all that. That text is from a 2004 RedMonk piece on adding compliance to SOA. It was – and is! – good stuff.
Reads sort of OK. The funny part is, Amazon’s web page is still used today as a frog to disect to learn how microservices work.
The cludgy parts helps highlight how microservices are different, esp. how coarse-grained the Amazon examples above are. Don’t get me wrong, I’m not being “that guy” here. Instead, I’m just trying to run the diff and find the right parts to highlight vs. the “computers are awesome” stuff you’ll see around any IT idea.
This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA, perhaps service orientation done right. Either way, the fact that SOA means such different things means it’s valuable to have a term that more crisply defines this architectural style.
Word up. Let’s try to make it work this time.