{"id":920,"date":"2018-12-16T04:55:24","date_gmt":"2018-12-16T04:55:24","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=920"},"modified":"2018-12-28T19:40:49","modified_gmt":"2018-12-28T19:40:49","slug":"do-microservices-make-soa-irrelevant","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/12\/16\/do-microservices-make-soa-irrelevant\/","title":{"rendered":"Do Microservices Make SOA Irrelevant?"},"content":{"rendered":"

Is service-oriented architecture, or SOA, dead? You may be tempted to
\nthink so. But that\u2019s not really true. Yes, SOA itself may have receded
\ninto the shadows as newer ideas have come forth, yet the remnants of SOA
\nare still providing the fuel that is propelling the microservices market
\nforward. That\u2019s because incorporating SOA principles into the design and
\nbuild-out of microservices is the best way to ensure that your product
\nor service offering is well positioned for the long term. In this sense,
\nunderstanding SOA is crucial for succeeding in the microservices world.
\nIn this article, I\u2019ll explain which SOA principles you should adopt when
\ndesigning a microservices app.<\/p>\n

Introduction<\/h3>\n

In today\u2019s mobile-first development environment, where code is king, it
\nis easier than ever to build a service that has a RESTful interface,
\nconnect it to a datastore and call it a day. If you want to go the extra
\nmile, piece together a few public software services (free or paid), and
\nyou can have yourself a proper continuous delivery pipeline. Welcome to
\nthe modern Web and your fully buzzworthy-compliant application
\ndevelopment process. In many ways, microservices are a direct descendant
\nof SOA, and a bit like the punk rock of the services world. No strict
\nrules, just some basic principles that loosely keep everyone on the same
\npage. And just like punk rock, microservices initially embraced a
\ndo-it-yourself ethic, but has been evolving and picking up some
\nstructure which moved microservices into the mainstream. It\u2019s not just
\nthe dot com or Web companies that use microservices anymore\u2014all
\ncompanies are interested.<\/p>\n

Definitions<\/h3>\n

For the purposes of this discussion, the following are the definitions I
\nwill be using.<\/p>\n

Microservices: The implementation of a specific business function,
\ndelivered as a separate deployable artifact, using queuing or a RESTful
\n(JSON) interface, which can be written in any language, and that
\nleverages a continuous delivery pipeline.<\/p>\n

SOA: Component-based architecture which has the goal of driving
\nreuse across the technology portfolio within an organization. These
\ncomponents need to be loosely coupled, and can be services or libraries
\nwhich are centrally governed and require an organization to use a single
\ntechnology stack to maximize reusability.<\/p>\n

Positive things about microservices-based development<\/h3>\n

As you can tell, microservices possess a couple of distinct features
\nthat SOA lacked, and they are good:<\/p>\n

Allowing smaller, self-sufficient teams to own a product\/service
\nthat supports a specific business function has drastically improved
\nbusiness agility and IT responsiveness (to any directions that the
\nbusiness units they support) want to take.<\/p>\n

Automated builds and testing, while possible under SOA, are now
\nserious table stakes.<\/p>\n

Allowing teams to use the tools they want, primarily around which
\nlanguage and IDE to use.<\/p>\n

Using-agile based development with direct access to the business.
\nMicroservices and mobile development teams have successfully shown
\nbusinesses how technologists can adapt to and accept constant feedback.
\nWaterfall software delivery methods suffered from unnecessary overhead
\nand extended delivery dates as the business changed while the
\ndevelopment team was off creating products that often didn\u2019t meet the
\nbusiness\u2019 needs by the time they were delivered. Even iterative
\ndevelopment methodologies like the Rational Unified Process (RUP) had
\nlayers of abstraction between the business, product development, and the
\ndevelopers doing the actual work.<\/p>\n

A universal understanding of the minimum granularity of a service.
\nThere are arguments around \u201cIs adding a client a business function, or
\nis client management a business function?\u201d So it isn\u2019t perfect, but at
\nleast both can be understood by the business side that actually runs the
\nbusiness. You may not want to believe it, but technology is not the
\nentire business (for most of the world\u2019s enterprises anyway). Back in
\nthe days when SOA was the king on the hill, some services performed
\nnothing but a single database operation, and other services were adding
\na client to the system, which led to nothing but confusion from business
\nwhen IT did not have a consistent answer.<\/p>\n

How can SOA help?<\/h3>\n

\"\" Want to learn more about
\nDocker, Kubernetes, and Rancher? Join us for free online
\ntraining After reading those definitions, you are probably
\nthinking, \u201cMicroservices sounds so much better.\u201d You\u2019re right. It is the
\nnext evolution for a reason, except that it threw away a lot of the
\nlessons that were hard-learned in the SOA world. It gave up all the good
\nthings SOA tried to accomplish because the IT vendors in the space
\nmorphed everything to push more product. Enterprise integration patterns
\n(which define how new technologies or concepts are adopted by
\nenterprises) are a key place where microservices are leveraging the work
\ndone by the SOA world. Everyone involved in the integration space can
\nbenefit from these patterns, as they are concepts, and microservices are
\na great technological way to implement them. Below, I\u2019ve listed two
\nother areas where SOA principles are being applied inside the
\nmicroservices ecosystem to great success.<\/p>\n

API Gateways (n\u00e9e ESB)<\/h4>\n

Microservices encourage point-to-point connections, and that each client
\ntake care of their own translations for dates and other nuanced things.
\nThis is just not sustainable as the number of microservices available
\nfrom most companies skyrockets. So in comes the concept of an Enterprise
\nService Bus (ESB), which provides a means of communication between
\ndifferent application in an SOA environment. SOA originally intended the
\nESB to be used to carry things between service components\u2014not to be
\nthe hub and spoke of the entire enterprise, which is what vendors
\npushed, and large companies bought into, and left such a bad taste in
\npeople\u2019s mouths. The successful products in the ESB have changed into
\ntoday\u2019s API gateway vendors, which is a centralized way for a single
\norganization to manage endpoints they are presenting to the world, and
\nprovide translation to older services (often SOA\/SOAP) that haven\u2019t been
\ntouched in years but are vital to the business.<\/p>\n

Overarching standards<\/h4>\n

SOA had WS-* standards. They were heavy-handed, but guaranteed
\ninteroperability (mostly). Having these standards in place, especially
\nthe more common ones like WS-Security and WS-Federation, allowed
\nenterprises to call services used in their partner systems\u2014in terms
\nthat anyone could understand, though they were just a checklist.
\nMicroservices have begun to formalize a set of standards and the vendors
\nthat provide the services. The OAuth and OpenID authentication
\nframeworks are two great examples. As microservices mature, building
\neverything in-house is fun, fulfilling, and great for the ego, but
\nultimately frustrating as it creates a lot of technical debt with code
\nthat constantly needs to be massaged as new features are introduced. The
\nother side where standards are rapidly consolidating is API design and
\ndescriptions. In the SOA world, there was one way. It was ugly and
\nbarely readable by humans, but the Web service definition language
\n(WSDL), a standardized format for cataloguing network services, was
\nuniversal. As of April 2017, all major parties (including Google, IBM,
\nMicrosoft, MuleSoft, and Salesforce.com) involved in providing tools to
\nbuild RESTful APIs are members of the OpenAPI Initiative. What was once
\na fractured market with multiple standards (JSON API, WASL, RAML, and
\nSwagger) is now becoming a single way for everything to be described.<\/p>\n

Conclusion<\/h3>\n

SOA originated as a set of concepts, which are the same core concepts as
\nmicroservices architecture. Where SOA fell down was driving too much
\ngovernance and not enough \u201cJust get it done.\u201d For microservices to
\ncontinue to survive, the teams leveraging them need to embrace their
\nancestry, continue to steal the best of the ideas, and reintroduce them
\nusing agile development methodologies\u2014with a healthy dose of
\nanti-governance to stop SOA
\nGovernance<\/a>
\nfrom reappearing. And then, there\u2019s the side job of keeping ITIL and
\nfriends safely inside the operational teams where they thrive. Vince
\nPower is a Solution Architect who has a focus on cloud adoption and
\ntechnology implementations using open source-based technologies. He has
\nextensive experience with core computing and networking (IaaS), identity
\nand access management (IAM), application platforms (PaaS), and
\ncontinuous delivery.<\/em><\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Is service-oriented architecture, or SOA, dead? You may be tempted to think so. But that\u2019s not really true. Yes, SOA itself may have receded into the shadows as newer ideas have come forth, yet the remnants of SOA are still providing the fuel that is propelling the microservices market forward. That\u2019s because incorporating SOA principles … <\/p>\n

Continue reading “Do Microservices Make SOA Irrelevant?”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-920","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/920","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=920"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/920\/revisions"}],"predecessor-version":[{"id":976,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/920\/revisions\/976"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=920"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=920"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=920"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}