Microservices development will fail with monolithic mindset
Enterprises that build microservices with traditional development tools and practices can run into problems in configuration and dependency management.
As monolithic applications become barriers to business agility, many organizations are breaking them down into microservices that are independently scalable and thus more cloud compatible.
In theory, microservices development should be simple -- at least when compared to building traditional monolithic apps. It's logical that small dev teams plus smaller apps and faster deployment would equal greater business agility. That equation, however, doesn't add up when organizations stick with traditional development approaches and technologies that don't fit the unique requirements of microservices.
Microservices development brings some common traps, and teams coming from monolithic application backgrounds may be caught off guard, said Bartosz Jedrzejewski, lead developer for UK consultancy Scott Logic.
Monolithic approaches to DevOps and configuration and dependency management, for example, often fail to handle the diversity and large number of microservices. Tools for building, deploying and managing microservices are available, but many of them are not adopted widely enough, Jedrzejewski said.
What's happening in your colleagues' siloes?
Most enterprises still keep separate development teams for each software project or type of software. An organization could have one team dedicated to monolithic applications, another for microservices and another for mobile apps. Moving away from siloed development teams requires the company to overcome IT inertia and make drastic changes, said Jay Lyman, principal analyst at 451 Research.
This is a challenge, and, without a unified DevOps practice, an organization can end up creating internal barriers to effective microservices development. These include overspending on tools and labor to create redundant or unneeded services.
Effective microservices development requires organizational change that goes beyond simple, single-team DevOps, said Brian Kirsch, an IT architect and instructor at Milwaukee Area Technical College. Without an overarching DevOps infrastructure across all projects, too many enterprises have created siloed DevOps mini-teams, each producing hundreds of microservices. It's not possible to create a cohesive product when each team works independently and doesn't know what others are doing, Kirsch said.
Maybe the name, microservices, makes people think they're supposed to be very, very small. That's not necessarily so.
Brad Irbysoftware architect
An important practice for organizations moving to microservices is to standardize development tools, frameworks and platforms. Standardization prevents overspending on tools and training and discourages expertise silos and competition for resources.
In siloed development, each team in a company often uses its own preferred technology. This reduces engineering resources, because developers may lack skill sets needed to switch teams or substitute on a team using another technology, Kirsch said. Also, it can be burdensome to maintain and update those tools.
Teeny, tiny or mighty microservices?
Enterprise IT's misconceptions about right-sizing services can create barriers to effective microservices development.
"Maybe the name, microservices, makes people think they're supposed to be very, very small. That's not necessarily so," said Brad Irby, a software architect and consultant based in San Francisco.
Brad Irby
Irby often helps companies recover from microservices sprawl caused by under-sizing microservices. The trouble is, maintaining and managing interactions among huge numbers of tiny microservices can be a nightmare, he said.
What's too small? An example is using a microservice like a repository that only handles inserts, updates and deletes. If there are 60 different tables in the database, then this practice results in 60 different microservices, Irby said. A better approach is crafting midsize microservices that support business goals. For example, use a microservice to implement a basic use case. Then use repositories to do the individual table updates, just as developers have done for years.
No microservice is an island
It can take two years to break a large application into domains and microservices. During the project, teams must maintain communication between the monolith and new microservices. "The most common mistake enterprise IT makes is not linking the monolith to the microservices," Irby said.
A scheduled turn-off, cutover day is another monolithic development practice that doesn't work for microservices. Breaking down a monolith should be a gradual process, in which connections between all parts are maintained, Irby said. Break off a piece of a monolith as a microservice, turn it on, and then put it into production alongside the monolith. Watch and learn how well the microservice works, and then slowly migrate over features.
Technical debt is a problem with monolithic apps, but it's worse with microservices, Jedrzejewski said. Instead of one big app riddled with delayed bug fixes, teams need to rework separate microservices individually. Microservices development mistakes are the main promulgators of technical debt, he said.
Teams should manage configuration and shared dependencies in microservices differently than they do for traditional applications, Jedrzejewski said.
Jay Lyman
A standard configuration approach for monolithic apps is to put a specific config file in each environment. Obviously, it's not practical to fit a configuration file to each microservice.
"Updating so many configurations would be difficult, if not impossible," Lyman said. Fortunately, configuration services -- such as Spring Cloud Config and Kubernetes ConfigMap -- automate most configuration tasks, including providing configuration values across microservices and updating configuration properties.
Managing interdependencies between microservices requires adherence to loose coupling practices. If the boundaries between two or more microservices are blurred, they may be interdependent. In these cases, the microservices are too narrowly focused, and teams should merge them into one microservice, Jedrzejewski said.
Old-school tools meet microservices
As development tools and methodologies rapidly change, interest in lightweight programming is on the rise. Businesses want to build applications without subscribing to an entirely new methodology. Instead, they want lightweight frameworks, said Steve Lane, CTO of Soliant Consulting, a Burlingame, Calif., software development services firm.
Ironically, development frameworks once considered lightweight -- like Ruby on Rails (RoR) -- don't meet microservices development requirements. Lane would recommend working with pieces of the Rails framework in tandem with other frameworks and tools.
Such middleware pipelines, or aggregations of targeted packages, replace traditional full-stack technologies like RoR and the Zend Framework. Recently, Lane has built microservices with lightweight middleware packages that provide a common lower-level plumbing and allow for a more targeted, opt-in package architecture. That wasn't practical in the past because full-stack frameworks needed to be monolithic. There were no common interfaces for things like HTTP requests, so frameworks rolled their own.
"To use traditional Zend Framework or Rails, you have to buy into the whole framework and do everything inside it, from persistence to logic to views." Lane said.
Now that the development community has embraced lower-level interfaces, true middleware pipelines are possible. Engineers can use a lightweight collection of targeted modules and stitch them together as the project requires, rather than having to pick a specific full-stack framework.
IT and DevOps leaders should expect challenges when transforming their organization's software development tools and frameworks for microservices development. Some engineers may object if their favorite tools aren't on the approved list. Leaders can overcome resistance by offering composite tool sets built from components of legacy programming frameworks.
The good news is that a microservice severely limits the blast radius of technical debt. "I have seen monolithic applications in such a horrible state that there was no hope in turning them around," Jedrzejewski said. "With microservices, because of their small sizes, there is always a chance."
Microservices are one of many emerging means to the end of digital transformation, Lyman said. It's not only in microservices development that holding on to traditional technologies and methodologies can create barriers to success. "There's no better or more urgent time to throw off IT inertia," he said.
Brad Irby
Jay Lyman
