This content is part of the Essential Guide: Taking a look at today's API management services and strategies
Get started Bring yourself up to speed with our introductory content.

Beware of complexity in API and microservices development

Finding the causes of cost overruns in software development and lifecycle is Theresa Lanowitz’s bailiwick. So, it’s natural that our recent conversation about technical debt in app development expanded beyond that subject. In this post, I share her insights on the hidden costs of API and microservices development and management, as well as some technologies that help software pros reduce those costs.

Theresa Lanowitz, founder, voke inc.

Theresa Lanowitz, founder, voke inc.

A well-known and sought-after consultant and speaker, Lanowitz founded voke inc., an analyst firm aimed focused on the evolving application lifecycle. Since its founding in 2006, voke’s surveys have uncovered hidden costs in Agile development, release management and other areas. Prior to founding voke, she served as a Gartner industry analyst and in leadership positions with Boeing, Borland Software and Sun Microsystems. She’s also a co-author, alongside voke COO Lisa Dronzek, of the book Lifecycle Virtualization.

API and microservices challenges

According to voke’s research, a minority of organizations automate API testing. Most often, the API owner or developer does some manual testing, releases the API and waits for feedback.

“Their attitude is, ‘If it works, great. If it doesn’t, we’ll deal with that later on,” said Lanowitz. “With this write-and-ship mentality, there’s no time to think about the cost of rework.”

Automating API tests would save time and money by eliminating manual tests and catching flaws before APIs are released. More importantly, said Lanowitz, better software releases result in happier customers. To make a relatively quick change to leveraging automation, she said, look at cloud-based API test tools.

Software quality vs. quick releases?

Speaking of better software releases, voke is seeing a shift away from a laser focus on fast time to market – a change in attitude compared to what used to be seen amongst organizations.

“In a recent survey, we asked which mattered most: time to market, quality or cost,” said Lanowitz. “People said quality is most important, and then time to market.”

The focus on speed has had the adverse effect of making technical debt a top ALM problem.

“We had so many people comment to us that focusing only on time to market is making costs skyrocket out of control,” said Lanowitz. “It’s taken this reality for people to finally say: ‘Let’s step back and take a look at how much we’re actually spending on this.’”

Hidden costs of microservices

In both API and microservices implementation, hidden complexities can add to costs. Changing from developing and managing an application to dealing with all the transactions in microservices makes control very difficult.

“The challenge with microservices is that even though you take the complexity down a level, you still have that complexity,” Lanowitz said. “You still have to reassemble those transactions back at the top and make sure that they’re all handled correctly.”

Lanowitz has seen DevOps teams struggle to manage microservices due to a lack of understanding of the services lifecycle. Here’s the bottom line: Don’t get into microservices if your organization doesn’t have really good, tried-and-true microservices management in place.

Ways to cut cost of API and microservices rework   

There are technologies that can diminish the challenges in API and microservices implementation. Lanowitz’s advice was to evaluate service virtualization, virtual and cloud-based labs, data virtualization and test data virtualization technologies. The latter helps keep data secure and reduces the cost of rework, because it makes it possible to perform testing with data as close to production as possible. She covers these technologies in depth in her aforementioned book.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

While Shadow IT may be pervasive, I disagree that IT simply needs to get over it. Embrace it, and bring it out of the shadows: yes. Shrug their shoulders and walk away: no.
Lurking behind every Shadow IT use of public cloud is a potential risk to the business that shouldn’t go unmanaged. Instead of accepting Shadow IT as the new normal, central IT should proactively bring unauthorized cloud use under IT management, ensuring providers meet SLAs, that proprietary customer data is housed in appropriate environments, and that the business is using the right decision criteria when selecting cloud services.
For more information on cloud management platforms as a control point:
- Derick Townsend, VP Product Marketing, ServiceMesh