Diagnosing problems across distributed applications -- particularly when you don't control many of the components -- is a real challenge. This article explains how troubleshooting cloud application performance issues requires wide area network (WAN) engineers and managers to embrace SOA-based management.
Cloud computing is exploding the application, breaking it up into a million tiny components. The cloud is service-oriented architecture (SOA) on an extreme scale, and it’s going to push network engineering to its limits. Where once an application’s pieces needed to communicate within a computer or across a LAN, today cloud applications need to talk across a combination of public and private networks, including the Internet and WAN links.
How cloud computing is SOA-based
In the 1980s, a team of developers started playing with Ada, the first object-oriented programming (OOP) language. The business benefits were compelling: The applications had fewer bugs, were developed faster and re-used greater amounts of code. The initiative failed, however, because only 15%of code was built in Ada, with most engineers sticking to the procedural languages they knew. IT engineers couldn't, or wouldn't, adopt this new way of thinking and behaving, and it took years for OOP to catch on.
Cloud computing is the Java-like trigger of SOA. The benefits -- and consequences -- of such a shift will change how we engineer networks and infrastructure forever.
Alistair Croll, Bitcurrent Principal Analyst
Much like Ada, SOA has always been a good idea in theory: Break an application up into its component parts -- storage, authentication, payment, mapping -- then connect them through simple interfaces. The result is a web of components, each of which can be improved independently of the others. But much like Ada, convincing people to use SOA has taken longer than it should. It took the rise of Java to really make OOP go mainstream.
Cloud computing is the Java-like trigger of SOA. The benefits -- and consequences -- of such a shift will change how we engineer networks and infrastructure forever. Extremely distributed applications with frequently-changing endpoints need new kinds of optimization, acceleration, and in-flight encryption; they also demand new service-level agreements (SLAs) and different ways of measuring performance.
Benefits of cloud services on applications
One of the benefits of a service-centric approach to application design was that services could be swapped out without changing the whole application. Now that we have access to a range of cloud services, we can, for example, replace a private payment tool with PayPal, Amazon Flexible Payment Services, or Google Checkout.
In fact, for nearly every component of an application, there’s a cloud alternative. Amazon itself has roughly 20 components, from message queues to large-object storage systems to parallel computing tools. Google has application performance interfaces (APIs) to rotate images, send emails and quickly query millions of records.
If your organization is building a composed application following SOA practices, then it has to choose between on-premise and cloud-based alternatives for each component. In many ways, the clouds have an unfair advantage:
- They enjoy economies of scale, since they have thousands of users. This means they have more, and better infrastructure that can handle spikes.
- They’re more reliable, because their architectures build redundancy into the system.
- They’re pay-as-you-go, because the provider amortizes cost across all its clients.
- They’re specialized. All PayPal does, for example, is worry about payment, so they can focus on fraud detection, build banking relationships and add payer dashboards in ways an internal developer wouldn’t.
Drawbacks of cloud applications
As a result, the applications that tomorrow’s developers hand network engineers will run across a million tiny links, relying on several specialized clouds. Management of this mesh of on-premise and on-demand applications will be a nightmare. Today’s cloud services have inconsistent management interfaces, meaning an application manager will have to manage many passwords and log in to different control panels to understand what’s broken. Troubleshooting will become more difficult than ever.
Accountability will go down, too. Many applications that assumed a quick response from local services will slow down significantly now that service calls have to travel from cloud to data center. Without good instrumentation of every component in an application, it will be hard to pinpoint where problems originate and who's responsible for particular components.
Another problem with cloud applications over SOA-based infrastructure is that these services aren’t standardized. While enterprises have had access to symmetric compression and WAN acceleration to speed up applications whose components are spread out around the world, these same tools may not work in an extremely distributed model. There’s no guarantee that the endpoints of the application are under the control of the networking team.
SOA-based management required for cloud applications
In the end, clouds give SOA proponents everything they dreamed of: a range of open, on-demand services that could be plugged and unplugged at will. But without the right understanding of the resulting risks, that dream could be a management nightmare, and the best laid plans of cloud applications could be destroyed by sluggish, hard-to-manage networks and unreliable components.
⇒ To understand how cloud computing challenges an IT manager's enterprise WAN strategy, read my previous article on the topic, or see SearchEnterpriseWAN.com's cloud computing tutorial for more information.