4

Building and running microservices at scale: A CTO’s view

 2 years ago
source link: https://www.infoworld.com/article/3648054/building-and-running-microservices-at-scale-a-ctos-view.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Building and running microservices at scale: A CTO’s view

How the 12-factor methodology, container-based microservices, and a monorepo approach win with both customers and developers at Priceline.

As The Innovator’s Dilemma tells us, today’s successful organizations will be increasingly challenged to adopt new processes in order to thrive. For modern organizations that rely on software development to sustain competitive advantage, this ever-present need for change requires reimagining the ways development teams work. Here at Priceline—one of the world’s most-frequented travel sites with millions of monthly visitors—that means adopting not only new and innovative technologies, but a whole new mindset around how we build and deploy services.

If we want to sustain success in a hyper-competitive marketplace, we must support a whole new set of service delivery strategies, and that requires thoughtfulness and diligence on the part of technology leadership. Our all-star team of technologists has rallied around 12-factor app development, monorepos, trunk-based development, and dependency management in an effort to lead technology evolution in the travel industry. But there’s much still to be done.

[ Also on InfoWorld: Why you should use a microservice architecture ]

Let’s consider container-based microservices. Enterprises are much farther along the adoption curve with containers and Kubernetes than was the case just a few years ago. According to a 2020 Cloud Native Computing Foundation Survey, the use of containers in production is up 300 percent since 2016. Today, 80% of Priceline’s entire product platform is running in Google Cloud on containers and Kubernetes.

Many large technology organizations are beginning to reap the benefits (and discover new challenges) of this paradigm shift in application development, but many more are just starting that journey. And the economics suggest that we’ll never employ enough devops and SRE experts to keep up with the accelerating demands of software development. CTOs everywhere need to be asking themselves not only how they can make their applications more resilient and scalable, but how they can put more responsibility in the hands of developers without overwhelming them with rote, manual work.

Green IT: The color of money
0 seconds of 21 minutes, 50 secondsVolume 0%

At Priceline, we developed a plan to modernize all of our applications around a single set of principles that put a focus on developer productivity. Here’s the how and why of that plan.

Switching to 12-factor to spur velocity and innovation

Even though Priceline has been around for over 20 years, it still operates like a startup in many ways. Continuous evolution here is not a luxury—it’s essential. Our customers’ behaviors and desires change frequently, and our competition is constantly finding new ways to match those needs. As a result, our developers innovate every day, whether it’s in the product, data, SDLC, or infrastructure, all while concurrently managing technical debt, software reliability, and security. It’s a gargantuan task.

The 12-factor methodology—the main tenets of which revolve around declarative formats, automation, and portability—allows our team to maintain a culture of innovation by decoupling our software from any infrastructure dependencies and ensuring that we are not locked into any one cloud, data center, software, or services provider. This means we can enforce an infrastructure arbitrage environment, and, over time, move workloads to any private or public cloud as the need arises.

The 12-factor methodology also calls for tight dependency management in the build process. This includes what’s running in our containers and the impact of changes to those containers—be they changes to the operating system or to our own code. The ability to declaratively check and instantiate our code early in the build process lets us validate changes earlier in the shipping process, leading to more innovation and reducing the overhead that comes from unwinding issues in production deployments.

Separating the build and run processes allows us to conduct automated functional testing and continuous deployment to further ensure velocity of our teams. Not only does this increase developer productivity and satisfaction, it allows us to more quickly test and improve customer-facing features, which ultimately results in better outcomes for our travelers and our business.

A customer-first approach

Our modernization plan has enabled us to transform our data and platform, delivering wins to customers and our business. By being able to stream data in real time, we can more quickly understand—and respond to—the activities and behaviors of customers on our platform. This allows us to better personalize our recommendations for where travelers want to go and stay, and helps us quickly experiment with new features and functionality.

Using a monorepo architecture in the software design process has allowed us to ensure a consistent customer experience. For example, our checkout components can now be built once and then leveraged by multiple teams, rather than having multiple different checkout components leading to a disjointed experience for the end user.

Teams can add their own features to those common components, and our platform teams have full visibility into what’s happening. Thus, no matter what features are added to the checkout experience, they will not compromise our software platform or performance metrics. Our monorepo architecture also makes upgrades more predictable, and shifts dependency management into the design and development process rather than finding issues in downstream deployments.

Disrupting software development

Our focus on the 12-factor methodology, container-based microservices, and a monorepo approach has advanced the software architecture that powers Priceline’s product platform. The benefits we’ve seen so far include:

  • Developers have greater control of how they design and develop software, as they are not bound to another team’s dependencies or tech stacks.
  • We have created a “developer first” mentality, thereby shifting most of the major responsibilities for the design and development into the hands of actual developers.
  • Developers are responsible for their own productivity. For example, I can design and develop a feature that is completely isolated and has no dependencies on other pieces of my infrastructure.
  • Applications are architected to build on the benefits of cloud infrastructure, rather than simply being developed on-prem then shipped to the cloud.

Where we go from here

Unfortunately, few of today’s tools make it easy to take advantage of strategies like 12-factor or monorepo architecture, and the software development arena is not yet where it needs to be to see innovative, cloud-native development practices take off like they should.

Today, only the most sophisticated technology organizations have people and budgets to dedicate to the problem. At companies like Priceline, with a multitude of skilled engineers, we can spin up DevX or platform teams to do this type of problem-solving at scale, but even this comes with an opportunity cost, namely developing new features for customers. Most enterprises—and certainly startups, small businesses, and legacy companies undergoing digital transformation—do not have this luxury at all.

In the future we’ll see declarative, next-generation CI/CD tooling that enables all companies to take advantage of these capabilities in a way that doesn’t require them to hire teams of people. At Priceline, we’ve already begun by working with innovative startups in this space. Startups like Slim.AI and others are pushing the boundaries of cloud-native and are likely to change the way we do modern software development at scale. Partnering with these new companies is critical for any enterprise technology firm to foster innovation.

According to the 2021 CNCF survey cited above, “complexity” has joined “cultural changes with the development team” as the top challenges in using and deploying containers. At Priceline, we have been successful in modernizing not just our tech stack, but our tech mindset. The curve continues to move outward, though, and the work is never done. Our focus on developer productivity will continue to play a central role in how we improve the customer experience and build better outcomes for our business.

Marty Brodbeck is the chief technology officer at Priceline. He has previously held top technology leadership positions at Shutterstock, Pearson, Diageo, and Pfizer, and currently advises several startups in the cloud technology industry.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to [email protected].


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK