From the Blogosphere
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
By: David Green
Feb. 1, 2017 02:00 PM
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
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.
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.
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
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.
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.
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.
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.
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?
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:
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.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week