Sometimes the best ideas start with a rant. At least that’s what happened to Mallika Iyer, a Cloud Foundry specialist at Pivotal who helps clients either start or expand their cloud efforts. After a particularly frustrating day, Iyer was complaining to her partner about the mistakes that clients seemed to make over and over again. His advice: make it a speech.
So last week attendees at Boston’s 2015 DevOps Days got to hear Iyer explain “Cloud Anti-Patterns,” which are a collection of five areas cloud implementations can go wrong. It’s good practical advice for anyone in the cloud space.
1. Ignoring the sweet spot: The sweet spot is a platform as a service or PaaS offering that can make all of the many moving parts of cloud adoption so much easier, Iyer explained. “Companies start on their journey and they think you need one tool to manage microservices, one to manage containers and one (or more) for continuous integration (CI) and continuous development (CD) tool sets,” she said. “Usually what ends up happening is they’re already creating silos. Now they’ve got three separate areas to manage instead of just one PaaS.” Her bottom line: “A PaaS allows you to align strategy with Dev and Ops teams and unifies your cloud strategy. Otherwise you’re going to exist in a silo’d world.” So think this through ahead of time and you’ll save time.
2. The logic leak: Although it’s tempting to have a whole lot of different but closely related microservices around when developing a product, problems arise when they’re too closely related (sharing a core object library or common domain objects) and suddenly “you’re going to end up with an inconsistent object at the end of the day,” Iyer warned. That results in the charmingly named “code smell” and is an easy trap to fall in to. Instead, remember DRY, for “don’t repeat yourself,” she said. And really, really don’t repeat similar logic.
3. Monolithic microservices: It’s tempting to put different microservices in the same container, right? Why not save money, and they’re all kind of related, and it’s a great idea, right? Wrong, said Iyer, though she acknowledged this practice is way more common than most people are willing to admit and more often than not the driving force is cost. But this strategy will cause your code to “decompose prematurely,” she warned, because microservices sharing the same container develop dependencies and suddenly making code changes – or scaling – becomes very difficult to do. “They grow arms and legs in there, so you just can’t put more than one in the same container,” Iyer said.
4. Ignoring the 3 Musketeers: Iyer referred to APIs/API interfaces, service registries and fault tolerance as the 3 Musketeers. APIs need to talk to each other but are often at cross purposes language-wise. Her advice is to use language independent Swagger to bridge all the gaps. “You need to honor the contract between your microservices,” she said. Service discovery is important because it can be easy to loose track of what is where with all the communication between APIs and the addition of new microservices. Her advice: Use Eureka from Netflix or Spring Cloud services. And finally, that third Musketeer, fault tolerance cannot be ignored because problems at the API layer can spread and potentially cause a disruption of service. Iyer suggested using Netflix’ Hystrix as “an elegant way to solve this problem.”
5. Siloed Search: Search can get tricky – and go stale – when all an application’s microservices are operating multiple sets of data and potentially altering them. The solution, Iyer said, is a cloud native federated search model. An enterprise wide data bus using Rabbit MQ or Kafka is the answer. “Instead of going from a formerly stale data push model now you have more of a proactive real time data model pulling from the message bus and updating, thus giving users the most up to date information,” Iyer said.
Has your organization been guilty of any of these “anti-patterns”?