Welcome!

@CloudExpo Authors: Elizabeth White, William Schmarzo, Todd Matters, Yeshim Deniz, Amitabh Sinha

Related Topics: @CloudExpo, Microservices Expo, @DevOpsSummit

@CloudExpo: Article

ESBs Are Made for This. Aren’t They? | @CloudExpo #ESB #Cloud #DevOps

The following fictional case study is a composite of actual horror stories I’ve heard over the years

The following fictional case study is a composite of actual horror stories I've heard over the years. Unfortunately, this scenario often occurs when in-house integration teams take on the complexities of DevOps and ALM integration with an enterprise service bus (ESB) or custom integration. It is written from the perspective of an enterprise architect tasked with leading an organization's effort to adopt Agile to become more competitive. The company has turned to Scaled Agile Framework (SAFe) as a way of scaling Agile, since initial attempts at Agile were not successful despite many scrum master training sessions.

I'm told that our SAFe implementation depends on the flow of information between people from different parts of the organization. Because these groups all use different tools, we need to focus on integrating them.

As senior director of Integrated Things for VeryLarge Corp., I have the expertise and know that my team can pull it off. Some of these tools are familiar to my team; we've already connected a couple of them to satisfy one use case, so I feel confident. ESBs are mature and the team is solid. Knowing that we've already deployed ESBawesome successfully makes me feel like this project is in the bag.

So how could I possibly fail? (Spoiler: Here's how):

ESBs Are Made for This
Choosing an ESB for this is easy. I want ESBawesome, since it's got good backing, super adoption and a great community. It has all the "ilities," including high availability, reliability and scalability. Plus it offers fault tolerance, security, tracking and monitoring.

With the tick boxes checked, I can see that ESBawesome already has a connector for some of the systems that we use: Atlassian JIRA and ServiceNow. And because of its API flexibility, ESBawesome can integrate anything. It even offers an easy way to generate connectors!

ESBawesome also fits in well with VeryLarge Corp.'s integration strategy; we've already got it deployed and we have a team built around it.

Team Capacity
The integration team's backlog isn't looking too bad. They're due to come off the current integration project, integrating the inventory-checking module with POS, and should be ready to begin in about six weeks.

Of course, there are a few hiccups. We're having problems with an upgrade of Atlassian's OnDemand JIRA service - where some of JIRAs changes regarding date handling in its REST APIs have caused hundreds of errors in our JIRA - ServiceNow integration. That, and we have to investigate why we've occasionally started seeing "Not authorized to perform action: Invalid key" errors from Rally. Oh, and we're currently blocking an upgrade of IBM RTC from 4.0.1 to 5.0.2 due to some changes and its client libraries from the old version not being compatible with the new version.

On top of that, I'm having multiple problems with the integrations that we've recently created. Not only were the integrations tricky, maintenance is much harder than we thought. These are taking my team more time than anticipated and, as a result, it's looking like a potential multi-month delay before I can even get started on this new integration effort.

Getting Started
It is three months later and we're finally getting started on our first SAFe integration use-case: quality group defect sharing with development. We've got our ESBawesome ESB application building in our CI environment, and we're deploying it continuously to a staging environment. We're operating at 40 percent capacity because the team is still dealing with the RTC upgrade, but we've got a great start in large part because of our previous ESBawesome experience.

To make the integration fault tolerant we've got to be sure to implement the ESBawesome "reliability patterns" correctly. We're using Oracle as a back-end relational database to help with that, but currently we're waiting on IT to set us up with an account with sufficient permissions to create the tables and sequences that we need.

The ESBawesome reliability patterns also call for a proper JMS queue, and we've finally got one going. It's not the same one that we'll use in production, but it's good enough for development. Hopefully things will just work when we switch over.

Connecting the Systems
It turns out that the JIRA connector for ESBawesome isn't all it's cooked up to be. It's definitely not designed for the kinds of use cases that we have in mind. The problem is that the low-level APIs of JIRA (and the connector) don't deal with JIRA issues as a whole - things such as watchers, links and comments are separate API calls.

Our first integration is all about connecting defects from the QA team with the development team. To do that we need the whole JIRA issue to reflect the state of defects filed in HPE ALM. Propagating only some of the state just won't do, so we have to deal with complexity such as a failure to update an issue with links after successfully creating it in JIRA. We're still trying to wrap our heads around how to manage such partially successful state replication.

On the HPE ALM side the ESBawesome connector is coming together slowly. We've had trouble getting the ESBawesome annotation-based REST connector to work for some of HPE ALM's API calls since we've discovered that some of the assumptions about REST APIs aren't holding true for HPE ALM.

Success
It's now four months since we kicked off this project, and the team has caught its first whiff of success. We've got issue creation in JIRA working! We had to hard code some values for some of the required fields in JIRA, but it works!

The next step is to make it easier to add new projects. Our teams in JIRA have all customized their projects with different statuses, fields and severities. I'm surprised at the lack of commonality among our 3,000 JIRA projects.

At the moment, each time we add a new project we have to hard code more values and field-specific logic into our ESBawesome application. The team knows this won't scale, so it has started creating an XML file to configure these settings. With three projects integrated, the XML file is over 4,000 lines. It's going to be tricky editing this file each time we add new projects, but we'd prefer to do that rather than have it hard coded in the application.

"ilities"
The team thinks that it has the fault tolerance and reliability aspects of the integration solved with the Oracle database and JMS.

We want to use ESBawesome's clustering capabilities for scalability and high availability, but we have to adapt some of our application logic to make that work. We chose the wrong level of abstraction for an integration unit of work, and have found that partial failures can result in issues with missing comments and others with duplicated comments, which causes a communication breakdown. Thankfully we haven't deployed into production yet, and it's not affecting any teams directly.

Our initial tests have shown that we don't really need clustering to scale to the levels we'll need with our 20,000+ developers. I'm cringing at the effort that we're spending on this.

We've had to pull in IT again since we'll need a load balancer in front of our ESBawesome cluster to handle transparent fail-over. It looks like they'll be meeting with us sometime next week to talk about environments, hardware allocation and timelines.

Domain Expertise
We've spent so much time trying to get the integration to work, sorting out the details with the technical bits (connectors, environments, databases and everything else) that we haven't had much time to test things with our users. Today we set up a mock trial with the quality group and it turns out that we completely missed something that's essential for this to work.

When an engineer resolves a defect, the quality team doesn't want it to show up as resolved in HPE ALM since they need to design and run tests to verify that it's indeed closed, and create the appropriate regression tests if needed. This only happens for defects in the ‘Ready for Verification' state - but we can't just move defects to that state without a quality engineer verifying that the change made it into a build that's been deployed to the QA environment. We proposed adding a new status, but that didn't fly because it would mess up their reports, so we're working on a way to have the "development status" show up in a new custom field in HPE ALM.

Deployed!
It's eight months since project kick-off and we now have a few "early adopter" teams trying out the new integration.

Initial feedback has been pretty good, but we now have a backlog of over 150 defects and feature requests. Most of them are minor, but a couple of them worry me. I'm not sure how we're going to deal with the loss of HTML formatting in descriptions for example, and HPE ALM's notion of comments as a single large text field is really problematic.

We had to put a few of our other integration projects on hold for awhile to get this one out the door, so we're switching gears right now to get those back on track. The team should be able to get back to this one in a couple of months, at which point we'll look at incorporating feedback from our users. If everything looks good, we'll be bringing on more teams into the trial and hopefully get the green light to deploy department-wide soon.

I'm feeling optimistic, but one of my engineers has given me a heads-up that Atlassian is about to delivery its next version of JIRA. I learned this happens about every six months. How in the world are we going to keep up?

Retrospective
Overall we failed the business. Looking back at what we accomplished, I'm really proud of my team. They overcame a lot of technical issues and really delivered. Unfortunately it wasn't enough.

It took eight months and a big chunk of my integration team's delivery capacity to deliver the first integration. The delay caused us to miss our SAFe implementation goals, and we only delivered a small piece of the integration puzzle. In the meantime, my team was unable to deliver on other projects, which is costing us in lost opportunities.

Here are some of the things we learned along the way:

  • Integrating teams is more complicated than we thought - the technology is only a part of integration. Understanding the reasons why and supporting specific integration use cases of multiple stakeholders is key.
  • This very quickly turned into a large development effort. Thankfully I have a top-notch team, but even they had to overcome some big problems. And there was constant pressure to deliver. VeryLarge Corp. really needed this up and running before we even started, and we simply couldn't deliver fast enough.
  • ESBawesome is a fabulous ESB. It really pulled through for us as a technology platform. The issue for us, though, was that ESB focused on the technical problem. As a result we were in the weeds a lot of the time. For DevOps and ALM/SDLC integration there was a great deal of customization and it was not straightforward. Using an ESB as the basis for our integration meant that we followed an industry-standard integration approach, but it also meant that a lot of software engineering was required. ESBs solve some of the problems, but come with their own complexity, requiring a high degree of expertise.
  • Connectors are a big part of the equation. ESBawesome only came with one of the connectors that we needed, so we ended up building the others ourselves. It's pretty quick to see some initial headway, but it is difficult to get these right. Building a connector means dealing with all of the idiosyncrasies and bugs of a third-party product API, which can vary from one version to the next.
  • The integrations that we built previously take a lot of effort to maintain. Through no fault of our own, APIs are changing and breaking in unexpected ways. This puts a heavy maintenance burden on my team. I'm going to have to plan for even more of this as we proceed with our integration strategy. I'll need to either cut the team's expected delivery of new features, or expand the team to account for maintenance.

It should be obvious that this enterprise architect went into the Agile scaling project unaware of the many technical and business challenges ahead, thereby spending an inordinate amount of time (and money) going down this route. Not till too far down the road did he understand that it can be very costly trying to accomplish this mission using only tools that his company already used. By then, his group had already failed.

More Stories By David Green

David Green is Vice President, Architecture at Tasktop. He was a founding member of MAKE Technologies, where he held the positions of CTO, vice president of technology and principal tools architect. At MAKE, he pioneered a model-driven approach to legacy modernization on the Eclipse platform, integrating business requirements, semantic code generation and data transformation.

David is an Eclipse committer and creator of Mylyn WikiText, a framework and tools for integrating wiki formatting into the Eclipse platform. He is well known for his widely read blog, Green's Opinion, apps for iPhone and Android, and speaking engagements at conferences such as JavaOne and EclipseCon.

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.


@CloudExpo Stories
It is ironic, but perhaps not unexpected, that many organizations who want the benefits of using an Agile approach to deliver software use a waterfall approach to adopting Agile practices: they form plans, they set milestones, and they measure progress by how many teams they have engaged. Old habits die hard, but like most waterfall software projects, most waterfall-style Agile adoption efforts fail to produce the results desired. The problem is that to get the results they want, they have to ch...
Cloud Expo, Inc. has announced today that Andi Mann and Aruna Ravichandran have been named Co-Chairs of @DevOpsSummit at Cloud Expo Silicon Valley which will take place Oct. 31-Nov. 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. "DevOps is at the intersection of technology and business-optimizing tools, organizations and processes to bring measurable improvements in productivity and profitability," said Aruna Ravichandran, vice president, DevOps product and solutions marketing...
We build IoT infrastructure products - when you have to integrate different devices, different systems and cloud you have to build an application to do that but we eliminate the need to build an application. Our products can integrate any device, any system, any cloud regardless of protocol," explained Peter Jung, Chief Product Officer at Pulzze Systems, in this SYS-CON.tv interview at @ThingsExpo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA
With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend 21st Cloud Expo October 31 - November 2, 2017, at the Santa Clara Convention Center, CA, and June 12-14, 2018, at the Javits Center in New York City, NY, and learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
The Internet giants are fully embracing AI. All the services they offer to their customers are aimed at drawing a map of the world with the data they get. The AIs from these companies are used to build disruptive approaches that cannot be used by established enterprises, which are threatened by these disruptions. However, most leaders underestimate the effect this will have on their businesses. In his session at 21st Cloud Expo, Rene Buest, Director Market Research & Technology Evangelism at Ara...
Wooed by the promise of faster innovation, lower TCO, and greater agility, businesses of every shape and size have embraced the cloud at every layer of the IT stack – from apps to file sharing to infrastructure. The typical organization currently uses more than a dozen sanctioned cloud apps and will shift more than half of all workloads to the cloud by 2018. Such cloud investments have delivered measurable benefits. But they’ve also resulted in some unintended side-effects: complexity and risk. ...
"Loom is applying artificial intelligence and machine learning into the entire log analysis process, from start to finish and at the end you will get a human touch,” explained Sabo Taylor Diab, Vice President, Marketing at Loom Systems, 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 are a monitoring company. We work with Salesforce, BBC, and quite a few other big logos. We basically provide monitoring for them, structure for their cloud services and we fit into the DevOps world" explained David Gildeh, Co-founder and CEO of Outlyer, in this SYS-CON.tv interview at DevOps Summit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend 21st Cloud Expo October 31 - November 2, 2017, at the Santa Clara Convention Center, CA, and June 12-14, 2018, at the Javits Center in New York City, NY, and learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
21st International Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy. Me...
SYS-CON Events announced today that Enzu will exhibit at SYS-CON's 21st Int\ernational Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Enzu’s mission is to be the leading provider of enterprise cloud solutions worldwide. Enzu enables online businesses to use its IT infrastructure to their competitive advantage. By offering a suite of proven hosting and management services, Enzu wants companies to focus on the core of their ...
In 2014, Amazon announced a new form of compute called Lambda. We didn't know it at the time, but this represented a fundamental shift in what we expect from cloud computing. Now, all of the major cloud computing vendors want to take part in this disruptive technology. In his session at 20th Cloud Expo, Doug Vanderweide, an instructor at Linux Academy, discussed why major players like AWS, Microsoft Azure, IBM Bluemix, and Google Cloud Platform are all trying to sidestep VMs and containers wit...
DevOps at Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with 21st Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to w...
Internet of @ThingsExpo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with 21st Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The Internet of Things (IoT) is the most profound change in personal and enterprise IT since the creation of the Worldwide Web more than 20 years ago. All major researchers estimate there will be tens of billions devic...
Amazon started as an online bookseller 20 years ago. Since then, it has evolved into a technology juggernaut that has disrupted multiple markets and industries and touches many aspects of our lives. It is a relentless technology and business model innovator driving disruption throughout numerous ecosystems. Amazon’s AWS revenues alone are approaching $16B a year making it one of the largest IT companies in the world. With dominant offerings in Cloud, IoT, eCommerce, Big Data, AI, Digital Assista...
The taxi industry never saw Uber coming. Startups are a threat to incumbents like never before, and a major enabler for startups is that they are instantly “cloud ready.” If innovation moves at the pace of IT, then your company is in trouble. Why? Because your data center will not keep up with frenetic pace AWS, Microsoft and Google are rolling out new capabilities. In his session at 20th Cloud Expo, Don Browning, VP of Cloud Architecture at Turner, posited that disruption is inevitable for comp...
SYS-CON Events announced today that Cloud Academy named "Bronze Sponsor" of 21st International Cloud Expo which will take place October 31 - November 2, 2017 at the Santa Clara Convention Center in Santa Clara, CA. Cloud Academy is the industry’s most innovative, vendor-neutral cloud technology training platform. Cloud Academy provides continuous learning solutions for individuals and enterprise teams for Amazon Web Services, Microsoft Azure, Google Cloud Platform, and the most popular cloud com...
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.
When growing capacity and power in the data center, the architectural trade-offs between server scale-up vs. scale-out continue to be debated. Both approaches are valid: scale-out adds multiple, smaller servers running in a distributed computing model, while scale-up adds fewer, more powerful servers that are capable of running larger workloads. It’s worth noting that there are additional, unique advantages that scale-up architectures offer. One big advantage is large memory and compute capacity...
No hype cycles or predictions of zillions of things here. IoT is big. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, Associate Partner at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He discussed the evaluation of communication standards and IoT messaging protocols, data analytics considerations, edge-to-cloud tec...