Big bang theory? Not for cloud-native development

Know your apps, know your workloads, know your team. In the third installment of this occasional series on cloud migration, Don Boulia, GM of IBM Cloud Developer Services, and guest Chris Condo, principal analyst at Forrester Research, discuss how cloud-native development teams can find more success through innovation, automation, and culture shifts.

How can cloud-native development teams help overcome the complexity of owning different parts of the application?

Chris Condo: Innovation. Teams don’t have to start from scratch. Cloud-native development provides things like serverless computing, elasticity, and scalability already built in.  Gone are the days when development teams are bogged down creating and maintaining every component of an application — cloud-native development allows teams to focus on what they’re good at, while leveraging necessary components, like seamless scalability, from cloud providers.

The caveat here is preparing your organization for this way of working. Because everyone is in a cloud environment, things are far more transparent than in the past when each team had their own dedicated systems, set up on premise by various developers who owned those pieces. Each team understood their environment but didn’t know what other teams were working on. In a cloud environment, you get a topographical view across the board, with the environments illuminated for coordination.

Don Boulia: I couldn’t agree more, especially when working with microservices. There’s a shift in the ability for teams to work in parallel and deliver updates and features to parts of a larger whole, wherein the monolith generation, features would get rolled in during long development cycles, a big bang effect. Today’s development promises 5-10 teams working independently but rolling out features in a coordinated way so we all make progress. There are rules that come along with that — it’s not a no-rule world, but the agility you get is paramount in a cloud world where users assume updates are always happening.

CC: Constant updates are possible because teams can now create environments on demand as necessary, scale up or down, and create and destroy test environments so there can always be a fresh start. There’s less friction for daily processes. Teams can share a single platform, collaborate and share components easily, and coordinate activities in a much more agile manner, thanks to the single dashboard view that’s now available.

How do you set up your teams to succeed? Where to start?

DB: I think automation is one of the fundamentals to most cloud-based environments, so you really have to foster a team culture that allows it to infiltrate. Manual steps and interventions become the killer to the agility, speed, and reproducibility of environments, so the expectation now and going forward is to plan for applications or workloads that can be easily recreated and torn down and brought back up.

A big piece of fostering that culture is how you organize your team. At IBM, we have a model of fairly small, complete teams with people defining the capabilities of a service from an offering management perspective, the features incorporated into development, and owning overall upkeep and availability. Teams are tightly clustered with the end-to-end responsibility for a component, which enables rapid delivery and the ability to respond quickly to customer feedback. And teams are doing this in parallel across an organization. That’s exactly the kind of invisible support people are looking for out of cloud.

CC: Good point. The fact that you’re developing and deploying in the same infrastructure enables the “you build it, you own it” mindset, which moves development agility along. More importantly, it focuses on customer needs, which in turn improves product quality and understanding where to focus your automation efforts. The environment you’re working in is no longer a distant land you have little access to — now you have ability to comb the logs and gain insights into what users are doing, so teams are much happier because they have evidence of the overall performance of their app.

DB: That’s the biggest shift in developing software and running cloud services: the end-to-end set of skills.  Developers can now understand both how to build an original feature set but also maintain and improve it over time, gaining customer feedback for constant improvement. As the old adage goes, “great power comes with great responsibility,” cloud-native development enables the business to drive forward and requires team accountability to take ownership of their part of the whole.

For a deeper dive into how companies are leveraging cloud native, explore the research.

The post Big bang theory? Not for cloud-native development appeared first on SD Times.

via Click on the link for the full article

Leave a Reply

Your email address will not be published. Required fields are marked *