Welcome!

Microservices Expo Authors: Stackify Blog, Aruna Ravichandran, Dalibor Siroky, Kevin Jackson, PagerDuty Blog

Related Topics: Microservices Expo

Microservices Expo: Article

Snow White's FIRST Web Services

A cautionary fable for IT management

One day, Snow White decided to deploy a Web service. Her IT dwarves immediately went to work and were pleasantly surprised to find how easy it was to create the Web service using modern development tools. To Snow White's development dwarves, it almost seemed like magic.

Since Snow White's cottage was a Java shop, they deployed the Web service in their J2EE application server, but they could have just as easily used .NET and it would have seemed just as magical - maybe even more so, given the wealth and power of the Wizard of Seattle.

Since Snow White had lived in a palace with a wicked witch, she was no stranger to corporate culture in general and risk aversion in particular. Snow White also had clear goals. She had wisely eschewed the use of magic mirrors, and tended to favor a few industry analysts along with a handful of software vendors who seemed both willing and able to partner with her for the long haul. She wanted to achieve a more flexible and agile IT infrastructure by gradually moving IT to a service-oriented architecture (SOA). Snow White understood that you can't build a robust SOA for your enterprise based on a foundation of unmanaged and unsecured Web services. She wisely instructed her IT dwarves to make sure that this first production Web service was manageable and secure before they implemented any other Web services.

Chapter One - The Stage Is Set
Security wasn't difficult to enable for their first Web service. Their application server provided a magical runtime environment that allowed developers to specify security declaratively within an XML file or using a pretty GUI. Her staff used this magic to make sure that their Web service, using WS-Security, would only work with client applications that supported XML Encryption and XML Signature. The identity of her customers was wisely required to be passed as a security token within the WS-Security element of the SOAP messages that she received. There was no need for federated identity management at this early stage since the cottage directory server had the IDs of all their customers firmly in hand, but they had a good plan to expand, as needed, toward a wider community of distributed identities in the future.

With their experience in building and securing a Web service behind them, Snow White's development dwarves next recommended the purchase of a Web services management product to monitor the availability of their Web services. As developers, they were particularly pleased that this product could manage a Web service without having to change a line of code. Also, the product could automatically discover and manage new Web services as needed. Automatic discovery was particularly important, since they were concerned about rogue Web services being deployed in the enterprise. Certain office productivity products had made this almost too easy, even for non-programmers. Of course, this Web services management product could also report on important service metrics and help make sure that the service was responsive and reliable.

Everything was tidy and in place, and Snow White felt safe, secure, and highly profitable in her little house in the woods. Everything seemed fine until one day the head IT dwarf (who used to be Sneezy before he found allergy medication) found his boss on the floor weeping. Six important customers had complained in the last hour about poor performance on the Web service. "How could this have happened?" demanded the tearful Snow White, "I thought you said that our Web services management software would warn us of potential problems!"

Chapter Two - What Went Wrong?
In truth, there were a number of IT management, development, and product evaluation issues that had contributed to Snow White's tears. One important issue was the ineffective and superficial integration between their existing enterprise management system and their new Web services management software. The operations staff was running the entire IT infrastructure (a multitude of hardware and software entities such as operating systems, application servers, messaging middleware, routers, networks, databases, networked storage, and so on) using an enterprise management solution from a different vendor than the one who had provided the Web services management software. This decision had unintended consequences.

Their Web services management software had correctly warned them that their Web service was performing poorly. So, from the perspective of the Web services developers, the Web services management software had performed admirably - reporting a wide variety of metrics that are typically of concern to the operations staff. It had even managed to send its messages to the enterprise management system console. But, the Web services management product used different terminology and had a different user interface than the enterprise management system. Despite some efforts to train some operations staff in the particulars of both management systems, in a crisis the staff was confused and frustrated. They found it difficult to work with two different management systems.

In terms of internal Web services expertise, Snow White had been forced to rely almost exclusively on the development organization since they had been the first to work with Web services. In retrospect, Snow White should have driven greater participation from her operations staff in the product evaluation - providing the training and consultative resources that they would need to better manage the issues from their perspective.

Web services management software is quite naturally focused on the higher-level specifics of Web services, such as messages and service descriptions (SOAP and WSDL). While such software can often identify a troublesome Web service even in complex aggregations of cooperating Web services, it quite properly lacks any root cause-analysis capability down to the IT infrastructure level. In other words, it isn't intended to trace the underlying cause of a problem down to a particular IT software or hardware entity, like a database or router. The underlying business logic and the supporting IT infrastructure are invisible to the Web services management software. So, in the case of Snow White's Web service performance problem, the operations staff had tried to correlate warning messages sent by the Web services management software with the large number of warning and error management messages related to underlying IT infrastructure and business logic reported by the enterprise management solution, but the lack of deep integration between the two management systems made such work tedious, time consuming, and error prone.

In retrospect, Snow White's strategy and evaluation team would have benefited from the understanding that management cannot be done piecemeal. As part of a comprehensive plan to properly manage new technology stacks such as Web services, on-demand computing, and Grid, the team should have considered the long-term interoperability, training, overhead, and partnership challenges that derived from the use of multiple management solutions. The IT dwarves had selected new Web services management software that was unlikely to enjoy a more useful level of integration with their enterprise software solution in the future. Were they prepared to deal with the added cost and complexity? Had they investigated Web services management products from their own enterprise management vendor? What was the current level of integration being offered by that vendor and, more importantly, what was the enterprise management software vendor's commitment to deeper, more useful levels of integration in future releases?

Of equal concern, the security officer had been absent from discussions concerning Web services management because of the common, but mistaken, notion that security and management are two entirely different concerns. These days, security management increasingly interacts with traditional areas of management such as systems and life-cycle management. The interoperability, visibility, and exposure provided by existing and emerging Web services standards are creating ever more interdependence between management and security. Consider the simple example of a denial-of-service attack on a Web service. Is this a Web services security issue (the enterprise is clearly under assault) or is this a Web services management issue (the service has experienced a change in utilization and SOAP message traffic)? The answer, ultimately, is both.

Many organizations are still in the early adopter phase of Web services use and might justifiably defer consideration of the inevitable convergence of security with other management concerns in the short term. However, Snow White's admirable commitment to an SOA and the deployment of her first production Web service clearly demonstrate that Snow White's strategy team should have had a long-term partnership and deployment plan in place that would allow them to steadily evolve their management and security operations toward a cohesive whole, as needed.

The absence of proper input by the security officer during the planning and evaluation phase also meant that enterprise-level security policy played a surprisingly small role in the decision by the development dwarves to utilize the Web services security functionality provided by the application server. While it is often true that platform-provided security can provide a relatively quick and inexpensive way to comply with enterprise Web services security and management concerns, this is not always the wisest course of action.

Tying security to the Web services platform can make it difficult to centrally administer and maintain policy in a heterogeneous enterprise. Even if the enterprise has standardized on one application server, there are often many other legacy processes and data sources that are not able to leverage the security and management capabilities provided by the Web services platform. In any heterogeneous SOA, integrated, enterprise-level Web services security and management solutions that are independent of the Web services platform may be the only way to ensure that all Web services, not just those deployed on the application server, are fully compliant with corporate policy and can be centrally monitored.

Conclusion
What conclusions can we draw from this IT management fable? Snow White's problem wasn't a poisoned apple (Snow White was not the kind of CxO to fall for that old trick!). It appears that even well-run IT organizations like Snow White's, with a clear vision of where they want to go, can be surprised by the complexity and challenges of managing and securing Web services as part of an SOA. The moral of the story is simple and of value to IT shops in enterprise cottages everywhere. To be useful in the long term, Web services management needs to be comprehensive and holistic - a carefully mixed potion of true Web services management genuinely integrated with IT infrastructure management. Also, in terms of implementing security for Web services, an important part of the total management equation, IT organizations would do well to look beyond the security needs of any particular Web service. Rather, they should begin to formulate a more comprehensive security and management policy and mechanisms that extend beyond any one Web services-enabled platform to serve the enterprise and the SOA as a whole. With these lessons learned, Snow White and her IT dwarves should live happily ever after.

More Stories By Paul Lipton

Paul Lipton is VP of Industry Standards and Open Source at CA Technologies. He coordinates CA Technologies’ strategy and participation in those areas while also functioning as part of CA Labs. He is co-chair of the OASIS TOSCA Technical Committee, and also serves on the Board of Directors of the open source Eclipse Foundation, as well as both the Object Management Group and the Distributed Management Task Force in addition to other significant technical and leadership roles in many leading industry organizations such as the OASIS, W3C and INCITS.

Lipton is also an approved US delegate to the international standards organization ISO, as a member of the subcommittee focused on international cloud standards. He is a founding member of the CA Council for Technical Excellence where he leads a team focused on emerging technologies, a Java Champion, and Microsoft MVP.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@MicroservicesExpo Stories
How is DevOps going within your organization? If you need some help measuring just how well it is going, we have prepared a list of some key DevOps metrics to track. These metrics can help you understand how your team is doing over time. The word DevOps means different things to different people. Some say it a culture and every vendor in the industry claims that their tools help with DevOps. Depending on how you define DevOps, some of these metrics may matter more or less to you and your team.
For many of us laboring in the fields of digital transformation, 2017 was a year of high-intensity work and high-reward achievement. So we’re looking forward to a little breather over the end-of-year holiday season. But we’re going to have to get right back on the Continuous Delivery bullet train in 2018. Markets move too fast and customer expectations elevate too precipitously for businesses to rest on their laurels. Here’s a DevOps “to-do list” for 2018 that should be priorities for anyone w...
If testing environments are constantly unavailable and affected by outages, release timelines will be affected. You can use three metrics to measure stability events for specific environments and plan around events that will affect your critical path to release.
In a recent post, titled “10 Surprising Facts About Cloud Computing and What It Really Is”, Zac Johnson highlighted some interesting facts about cloud computing in the SMB marketplace: Cloud Computing is up to 40 times more cost-effective for an SMB, compared to running its own IT system. 94% of SMBs have experienced security benefits in the cloud that they didn’t have with their on-premises service
DevOps failure is a touchy subject with some, because DevOps is typically perceived as a way to avoid failure. As a result, when you fail in a DevOps practice, the situation can seem almost hopeless. However, just as a fail-fast business approach, or the “fail and adjust sooner” methodology of Agile often proves, DevOps failures are actually a step in the right direction. They’re the first step toward learning from failures and turning your DevOps practice into one that will lead you toward even...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
While walking around the office I happened upon a relatively new employee dragging emails from his inbox into folders. I asked why and was told, “I’m just answering emails and getting stuff off my desk.” An empty inbox may be emotionally satisfying to look at, but in practice, you should never do it. Here’s why. I recently wrote a piece arguing that from a mathematical perspective, Messy Desks Are Perfectly Optimized. While it validated the genius of my friends with messy desks, it also gener...
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
The enterprise data storage marketplace is poised to become a battlefield. No longer the quiet backwater of cloud computing services, the focus of this global transition is now going from compute to storage. An overview of recent storage market history is needed to understand why this transition is important. Before 2007 and the birth of the cloud computing market we are witnessing today, the on-premise model hosted in large local data centers dominated enterprise storage. Key marketplace play...
The cloud revolution in enterprises has very clearly crossed the phase of proof-of-concepts into a truly mainstream adoption. One of most popular enterprise-wide initiatives currently going on are “cloud migration” programs of some kind or another. Finding business value for these programs is not hard to fathom – they include hyperelasticity in infrastructure consumption, subscription based models, and agility derived from rapid speed of deployment of applications. These factors will continue to...
Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task ...
Following a tradition dating back to 2002 at ZapThink and continuing at Intellyx since 2014, it’s time for Intellyx’s annual predictions for the coming year. If you’re a long-time fan, you know we have a twist to the typical annual prediction post: we actually critique our predictions from the previous year. To make things even more interesting, Charlie and I switch off, judging the other’s predictions. And now that he’s been with Intellyx for more than a year, this Cortex represents my first ...
"Grape Up leverages Cloud Native technologies and helps companies build software using microservices, and work the DevOps agile way. We've been doing digital innovation for the last 12 years," explained Daniel Heckman, of Grape Up 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.
The Toyota Production System, a world-renowned production system is based on the "complete elimination of all waste". The "Toyota Way", grounded on continuous improvement dates to the 1860s. The methodology is widely proven to be successful yet there are still industries within and tangential to manufacturing struggling to adopt its core principles: Jidoka: a process should stop when an issue is identified prevents releasing defective products
We seem to run this cycle with every new technology that comes along. A good idea with practical applications is born, then both marketers and over-excited users start to declare it is the solution for all or our problems. Compliments of Gartner, we know it generally as “The Hype Cycle”, but each iteration is a little different. 2018’s flavor will be serverless computing, and by 2018, I mean starting now, but going most of next year, you’ll be sick of it. We are already seeing people write such...
Defining the term ‘monitoring’ is a difficult task considering the performance space has evolved significantly over the years. Lately, there has been a shift in the monitoring world, sparking a healthy debate regarding the definition and purpose of monitoring, through which a new term has emerged: observability. Some of that debate can be found in blogs by Charity Majors and Cindy Sridharan.
It’s “time to move on from DevOps and continuous delivery.” This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.” Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transfo...
Let's do a visualization exercise. Imagine it's December 31, 2018, and you're ringing in the New Year with your friends and family. You think back on everything that you accomplished in the last year: your company's revenue is through the roof thanks to the success of your product, and you were promoted to Lead Developer. 2019 is poised to be an even bigger year for your company because you have the tools and insight to scale as quickly as demand requires. You're a happy human, and it's not just...
"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.