Cloud Native / Development / Sponsored / Contributed

6 Cloud Native Do’s and Don’ts for Developers

14 Dec 2020 3: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.

Developers around the world are deep into one of the biggest software transformations yet: the migration away from monolithic, single-node applications to microservice-based, cloud native applications running on distributed systems. It might not be as big a shift as the move from punch cards to human-readable programming languages, but it’s up there.

Lightbend recently completed a survey of more than 1,000 developers and other IT decision-makers, shedding light on the challenges enterprises face during this shift and how they’re facing them. Here’s what you — as a developer or software engineer tasked with navigating this new landscape — can take away from this research:

Don’t forget why you’re adopting cloud native technologies.

It’s easy to get so caught up in the question of what technologies you’re using, that you forget why you’re using them in the first place. But remember that adopting cloud infrastructure — whether it’s a Kubernetes cluster in your own data center, or serverless API in the public cloud — isn’t the goal. The goal is to help your organization build more scalable and flexible applications and to do it quicker. If you’re not actually taking into account the advantages and disadvantages of cloud infrastructure when you build applications, there’s a good chance you’re not actually meeting your organization’s real goals.

Do design cloud native applications to handle unresponsive or broken components.

Nodes crash. Networks fail. Remote APIs give unexpected results. Cloud native development requires you to handle these problems gracefully. Applications need to give users some sort of response, even if a component, or several components, are broken or non-responsive. You also need to think about how to recover once the broken or unavailable component is working again. Check out the Reactive Principles for additional guidance and techniques for getting started.

Don’t forget about security and compliance.

Cloud native applications have unique compliance and security challenges. Executives interviewed for the survey said again and again that they wished developers would put more thought into these issues up-front. Developers who loop security and compliance teams into the development process early — and are willing to put the work in to understand their industry’s security and compliance requirements — will not only get ahead in the workplace, but likely save themselves and their teams work by avoiding the need to refactor features or entire applications further down the development cycle.

Do locate functionality that can be shifted to microservices or serverless sooner than later.

Cloud native development isn’t an all-or-nothing proposition. You don’t have to throw out all your monoliths at once. You can build greenfield applications with a microservices orientation while looking at all your existing monolithic applications and thinking about what functionality could be broken off. Features shared across multiple applications, like payment processing, are a good candidate. So are CPU-intensive features that could slow down an entire application. Image transformation is a classic example of something that might be best run separately on a function-as-a-service (FaaS) platform. Instead of forcing a user to wait for an application to resize some images they uploaded, the FaaS can handle that task while the rest of the application chugs along.

Don’t assume more configurable or portable solutions are a “silver bullet.”

It’s tempting to rely on frameworks that give developers plenty of options and that are fully portable from one cloud to another. But more choices and control also mean more complexity and more responsibility for maintenance. The result is more work for you and less time to focus on building features that provide business value. Sure, relying on a cloud provider’s special features will make your application less portable. But if you’re not tapping into the resources those providers offer, are you really getting the full possible value from the cloud? Sometimes it’s best to sacrifice a little control in favor of agility and the ability to focus more on what matters.

Do determine what trade-offs are acceptable to your organization.

Building cloud native applications is all about trade-offs. You need to understand those trade-offs and make educated decisions about what your organization is and isn’t willing to sacrifice. This will usually mean making compromises with the management team. Make sure your technical goals are aligned with their business goals.

Conclusion

The massive shift towards cloud native environments will require you to give up much of what you’re familiar with, from architecture to development processes to frameworks. It will also mean ceding a certain amount of control over parts of an application. But the change will also be liberating, freeing you from much of the drudgery of development work as you focus on higher-level features. The migration means getting to focus more on what probably got you interested in programming in the first place.

Download your copy of Cloud Native Adoption Trends 2020-2021 to explore the ongoing tension between developers and IT leaders 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.