Welcome!

Microservices Expo Authors: Pat Romanski, Flint Brenton, Yeshim Deniz, Elizabeth White, Liz McMillan

Related Topics: Microservices Expo

Microservices Expo: Article

Scaling SOA

Implementing SOA comes with overhead, but smart architecture can lead to infinitely scalable SOA implementations

Based upon conversations with architects in ZapThink’s Licensed ZapThink Architect (LZA) course, our High Performance SOA ZapFlash back in the fall of 2006 was a bit ahead of its time. In 2006, most architects were simply focusing on how to put SOA implementations together, but today, the focus has unquestionably shifted to how to make SOA implementations enterprise-class. As a result, there is predictably an increasing emphasis on scalability.

Conventional wisdom might suggest that SOA implementations scale poorly. While it’s true that abstraction layers always add some overhead, if your SOA implementation is too slow or doesn’t scale properly, the problem is more likely with how you went about architecting it, rather than a problem with the SOA approach itself. Understanding the best practices for building scalable, high performance SOA implementations, therefore, is an essential skill for any SOA architect.

The Three Dimensions of Scalability
Building scalable SOA implementations begins predictably with broad-based scalability best practices. The SOA architect must then understand how to apply these practices in the SOA context. SOA introduces some new scalability challenges to be sure, but from the systems perspective (where scalability lives), SOA is just one more approach for accessing enterprise resources.

The scalability approach this ZapFlash will focus on is called the “Scalability Cube,” which is one way of looking at the core best practices for enterprise scalability. This cube has three dimensions, which you can think of as the X, Y, and Z axes. Basically, there are three essentially orthogonal approaches to scalability, and the architect’s challenge is in properly combining them to achieve the best results.

Each axis consists of multiple instances of an underlying implementation. Each instance contains some subset of the infrastructure necessary to support one or more Services, including data stores, data integration technology, legacy applications and integration technology, Service run time containers, and whatever middleware glues the lot together. The key to scaling the SOA implementation is to duplicate such instances in particular ways depending upon which axis we’re following.

The most straightforward scalability dimension is the X axis. The X axis represents the distribution of the same work or mirroring of data. To scale an implementation along the X axis, deploy multiple identical systems that are essentially mirror images of capabilities and data. A typical example of X axis scaling would be multiple identical databases on the back end supporting identical Service implementation instances. Scaling out, then, depends upon the straightforward process of adding identical instances.

The advantages of scaling along the X axis are as follows:

  • It’s simple to implement and simple to scale out. Simply distribute Service requests via a simple round robin algorithm on a load balancer or other intermediary.
  • It provides the best recovery from failure. If anything goes wrong with one of the instances, simply route traffic to other instances until you fix the problem. As a result, most disaster recovery strategies rely upon X axis scalability.
  • It works well with Entity Services, because Entity Services tend to abstract database tables or data integrations, which easily fit into an X axis instance.

There are disadvantages of X axis scaling as well:

  • It doesn’t maintain process instance state well, because multiple requests from the same consumer may be routed to different X axis instances in an essentially random fashion. Therefore, you must typically rely on messages to maintain state, which may require custom message headers and Service contracts.
  • X axis scaling doesn’t work for Services that abstract legacy systems that can’t be duplicated further. If you only have that one old mainframe acting as the back end for your Services, it will prevent X axis scaling of the infrastructure that supports the Service interfaces to the legacy system.

Orthogonal to the X axis is the Y axis, which represents the distribution and separation of work responsibilities or data across multiple instances. The distribution of capabilities along the Y axis are by resource, and such instances separate data based on data type or type of work. An example of scaling along the Y axis would be where each database and corresponding middleware instance supports a separate set of Services. To scale up, run fewer and fewer Services on any particular implementation instance as you add instances.

The advantages of Y axis scaling are:

  • It’s the best way to scale reusable Services. As the demand for reusable Services increases, their implementations can be distributed to as many implementation instances as necessary.
  • It works well with Task Services, because Task Services are less likely to abstract capabilities across multiple data sources as Entity Services are.
  • Y axis scaling also works well for abstracting legacy systems that can’t be duplicated further, although the scalability of such systems will still impact the overall scalability of the Services that abstract them. (Resolving that issue typically involves some kind of caching scheme.)

The disadvantages of Y axis scaling are:

  • Entity Services that abstract complex joins do poorly with Y axis scaling, because the complexity of the underlying implementation limits how narrow each instance can become.
  • Y axis scaling also deals with state poorly, when compositions include Services from different Y axis instances. However, because it’s possible in some cases to plan for Y axis scaling that maintains compositions in separate Y axis instances, it can maintain state more effectively than X axis scaling some of the time.

Finally, the Z axis represents distribution and segmentation of work by customer, customer need, location or value, in other words, by Service consumer or by type of request. For example, each database and corresponding Service container instance supports a separate, pre-defined set of consumers.

The advantages of Z axis scaling include:

  • It’s the best approach for addressing the state issue of the other approaches. There’s no chance a user’s state will be lost within the context of a particular Z axis instance, as long as that instance is working properly.
  • In some cases, individual compositions could also be allocated to individual Z axis instances, if different consumers consume different processes implemented by those compositions. This advantage would only apply for those processes that are specific to particular consumers.

The disadvantages of Z axis scaling are:

  • It doesn’t work well for reusable Services, for obvious reasons: consumers assigned to one Z axis instance can’t consume Services in another.
  • Z axis scaling also doesn’t deal well with legacy systems that can’t be duplicated further, as with X axis scaling.

Putting the Cube Together
In general, no one axis is sufficient to scale a SOA implementation fully. The architect must plan combinations of approaches that fit into the Cube as though it were a Chinese puzzle. Some examples of pairwise combinations are as follows:

  • X and Y axis — mirrored, identical clusters of servers, where each server in a particular cluster runs some set of Services distinct from the other servers in the cluster. Alternately, the X and Y axis combination might be several clusters, where each cluster addresses a specific set of Services, and each cluster is made up of a set of mirrored, identical servers.
  • X and Z axis — mirrored, identical clusters of servers, where each server in a particular cluster is dedicated to requests from a specific subset of consumer requests. Alternately, the X and Z axis combination might be several clusters, where each cluster addresses a specific subset of consumers, and each cluster is made up of a set of mirrored, identical servers.
  • Y and Z axis — a set of clusters of servers, where each cluster hosts a set of Services and each server in a cluster responds to requests from a particular set of consumers, or vice versa, naturally.
  • X, Y, and Z axis — Leveraging the full cube essentially requires clusters of clusters. There are too many possibilities to list here, so we’ll leave this option as an exercise for the reader!

The ZapThink Take
It’s important to remember that scalability, for all its complexity, is still only one part of the SOA performance problem. High performance begins with good design, as design mistakes like improper Service granularity or overly complex schemas can sink your performance. It’s just as important to deal with potential bottlenecks, which in the SOA case, typically involve XML processing issues of various sorts. High performance SOA means getting all of these elements right, as any one of them can limit the overall performance of your implementation.

We’d like to hear from you about your SOA performance challenges and solutions! Please email us at [email protected] if you have any SOA performance stories — either horror stories or success stories. If you have a product or service that can help with SOA performance, we’d like to hear from you too! We’ll use the information we receive in our presentation at our upcoming High Performance SOA seminar in New York City on March 29th. Watch the new ZapThink Web site for more information on that event as it develops. Hope to see you there!

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.

@MicroservicesExpo Stories
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
Don’t go chasing waterfall … development, that is. According to a recent post by Madison Moore on Medium featuring insights from several software delivery industry leaders, waterfall is – while still popular – not the best way to win in the marketplace. With methodologies like Agile, DevOps and Continuous Delivery becoming ever more prominent over the past 15 years or so, waterfall is old news. Or, is it? Moore cites a recent study by Gartner: “According to Gartner’s IT Key Metrics Data report, ...
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
You often hear the two titles of "DevOps" and "Immutable Infrastructure" used independently. In his session at DevOps Summit, John Willis, Technical Evangelist for Docker, covered the union between the two topics and why this is important. He provided an overview of Immutable Infrastructure then showed how an Immutable Continuous Delivery pipeline can be applied as a best practice for "DevOps." He ended the session with some interesting case study examples.
Both SaaS vendors and SaaS buyers are going “all-in” to hyperscale IaaS platforms such as AWS, which is disrupting the SaaS value proposition. Why should the enterprise SaaS consumer pay for the SaaS service if their data is resident in adjacent AWS S3 buckets? If both SaaS sellers and buyers are using the same cloud tools, automation and pay-per-transaction model offered by IaaS platforms, then why not host the “shrink-wrapped” software in the customers’ cloud? Further, serverless computing, cl...
All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
"We view the cloud not as a specific technology but as a way of doing business and that way of doing business is transforming the way software, infrastructure and services are being delivered to business," explained Matthew Rosen, CEO and Director at Fusion, in this SYS-CON.tv interview at 18th Cloud Expo (http://www.CloudComputingExpo.com), held June 7-9 at the Javits Center in New York City, NY.
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that e...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...
"DivvyCloud as a company set out to help customers automate solutions to the most common cloud problems," noted Jeremy Snyder, VP of Business Development at DivvyCloud, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
We all know that end users experience the Internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices – not doing so will be a path to eventual b...
"This all sounds great. But it's just not realistic." This is what a group of five senior IT executives told me during a workshop I held not long ago. We were working through an exercise on the organizational characteristics necessary to successfully execute a digital transformation, and the group was doing their ‘readout.' The executives loved everything we discussed and agreed that if such an environment existed, it would make transformation much easier. They just didn't believe it was reali...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes a lot of work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost ...
Your homes and cars can be automated and self-serviced. Why can't your storage? From simply asking questions to analyze and troubleshoot your infrastructure, to provisioning storage with snapshots, recovery and replication, your wildest sci-fi dream has come true. In his session at @DevOpsSummit at 20th Cloud Expo, Dan Florea, Director of Product Management at Tintri, provided a ChatOps demo where you can talk to your storage and manage it from anywhere, through Slack and similar services with...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Archi...
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...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...