Cloud Native / DevOps / Sponsored / Contributed

6 Cloud Native Do’s and Don’ts for IT Executives

4 Jan 2021 6:00am, by

Lightbend sponsored this post.

Klint Finley
Klint Finley is a professional writer and analyst who specializes in enterprise computing and developer technology. He served as a staff writer at Wired for nearly eight years where he reported on such topics as artificial intelligence, cloud computing, and data science. His work has also appeared in ReadWriteWeb, TechCrunch, and BoingBoing. Klint is based in Portland, Oregon.

Lightbend recently conducted a survey of more than 1,000 developers and other IT decision makers. The report sheds light on what developers wish IT executives better understood about cloud native technologies, as well as challenges faced by enterprises making the transition to new technologies.

Here are a few best practices gleaned from the research, to prepare your organization for success in 2021:

Do understand what technology can’t do.

One common theme in written responses to the survey from developers is that business leaders need to understand that cloud computing isn’t a “silver bullet” or “magical,” suggesting that IT executives might be putting a little too much faith in technology to solve business problems. Moving to containers or to serverless won’t necessarily save your organization money or free up time for your developers. Spend time with your technologists and understand what can’t be solved with technical fixes. Put your business goals first and think about how technology can best serve those goals.

Don’t underfund application-level projects.

It’s easy to think about “the cloud” primarily as infrastructure. But lifting and shifting legacy applications to the public cloud or a Kubernetes cluster in your own data center will be a wasted effort if those applications can’t take full advantage of that infrastructure. That means devoting the necessary resources for re-architecting or replacing applications. Otherwise, the spending on infrastructure might be wasted.

Do create greenfield applications with microservices in mind.

Microservices allow your developers to move faster by working on discrete chunks of functionality without worrying about breaking someone else’s code. They also keep your teams from replicating each other’s work, because any application can consume a well-designed microservice — regardless of what application it was originally created for. Ultimately, it should mean more reliable software, built more quickly by happier dev teams. Start by building greenfield applications with microservice-oriented architectures. As your teams reorient themselves towards this new way of building applications, it will be easier to retool existing applications in a microservice-oriented manner. Check out Microservices Unleashed for additional insights.

Don’t let your teams get stuck feeding infrastructure and commodity functionality.

Will having your developers build and support a custom authentication system add value to your business? Do they really need to keep maintaining all those databases? The answer in some cases may be “yes.” But all too often IT staff are stuck maintaining systems that could just as easily be outsourced to cloud providers, allowing them to refocus their efforts on more valuable work. You’ll need to do a clear-eyed assessment of your IT landscape and think about what should and shouldn’t be handled in-house. In some cases, it might cost more money to outsource a service, but it’s often the case that freeing up staff for more innovative work makes increased costs worthwhile.

Do reorganize teams as necessary.

As developer teams refocus on building microservices and outsource commodity functionality to cloud providers, it might be necessary to shift teams around. Some developers, for example, might become responsible for microservices used by multiple different departments. Some organizations may find that managing cloud services is a job in itself. Likewise, shifting from the classic waterfall development process to more cloud-friendly agile and CI/CD processes will likely require organizational changes as well. Don’t expect the org chart to remain static while your development work becomes more dynamic.

Don’t allow the configuration vs. automation conundrum to derail your cloud strategy.

One of the biggest differences we saw between developers and IT executives is that developers prefer the control that comes with highly configurable frameworks, while IT executives would prefer their organizations shift as much as possible towards automation and *aaS offerings. It’s important that everyone understand the trade-offs involved with both and make firm decisions accordingly. There may be good technical reasons to maintain more control and customization of a particular application. In other cases, management needs to make it clear to developers that some features simply aren’t a high priority and should be outsourced.

Conclusion

You could boil most of these insights down to a single word: communication. The shift towards cloud native environments is one of the biggest shifts in the history of software development — right up there with the transition away from punch cards and towards human readable programming languages. IT executives need to work closely with the technical teams to ensure that everyone understands the goals of the business and how the technology strategy fits in.

Download your copy of Cloud Native Adoption Trends 2020-2021 to explore the ongoing tension between developers and IT executives about what the highest priorities are for cloud native migrations.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.