devopsy.kinsta.cloud

Tag: continuous delivery

  • Predictions 2020: How to Make the Case for Adopting CI/CD in Your Organization

    Predictions 2020: How to Make the Case for Adopting CI/CD in Your Organization

    The practice of continuous integration and continuous delivery (CI/CD) is fundamental to modern software development. And yet, many organizations are still using slow, error-prone, manual processes to build, test and deploy their software. Sometimes, the blocker can be engineers who don’t want to change how they’ve always done things, but most often folks in the trenches are chomping at the bit to automate. All too frequently, it is IT leadership and executives who need to be convinced that making a large investment in updating tools, training and culture will net returns greater than the cost.

    If you want to change management’s mind about an investment in CI/CD, focus on making a strong business case. This may sound daunting, but it’s easier than you think. Learning a bit about how to advocate for budget and organizational change can go a long way. Just think about what life would be like if, instead of sitting in endless change management meetings, you could get your code to production simply by merging to master while automation takes care of the rest.

    This article will get you started with some concrete tips you can use to get CI/CD green-lit by your leadership.

    Start Small

    Agile and DevOps are all about breaking things up into smaller chunks. It may seem counterintuitive, but deploying more frequently equates to less risk because small changes are easier to orchestrate, troubleshoot and roll back than large complicated deployments. In that same way, you can reduce the risk to the organization by taking a DevOps approach to transformation. Rather than trying to upend your entire process, see how you can break the change up into small, iterative chunks.

    Almost every large enterprise that has successfully adopted wide-spread CI/CD started with one lighthouse team. Changing everything is a tough sell. Instead, approach management with a low-risk proposal: “We’d like to run an experiment to see if we can deliver more quickly and reduce costs. We have one team that will take one small project and test CI/CD automation to see what the results will be. We can leverage open source tooling to get started at a low cost.” Even the most stingy budget holder should find the proposal intriguing.

    Measure the Results

    Once you’ve started to conduct your experiment, it’s important to measure what you observe. What are the differences between the old way and the new way? The more concretely you can quantify it, the better. Saying, “We went faster,” doesn’t carry a lot of weight. But if you can quantify it, your message becomes more potent. For example, “Our previous cycle time from the moment a developer begins work on a ticket to the time that code is running in production and useable was 30 days. By automating some of our manual efforts using CI/CD we have cut that to five days.”

    For this part of the process there’s no need for exact numbers. Most likely if you aren’t doing CI/CD today, you likely don’t have the instrumentation in place to accurately measure cycle time. But don’t let that be a blocker. You can give estimates. “From about one month to one week,” is still a powerful story.

    Some other metrics to capture that can help make your case are:

    • Number of tests run.
    • Code coverage in terms of percentage of code tested.
    • Number of people-hours required.
    • Number of defects in production or number of regressions/roll backs needed.
    • Mean time to repair (MTTR): The average time from when a bug/failure is discovered in production to when the fix is running.
    • Frequency of releases—how often new capabilities are available for users.
    • Cost to deploy: This is a very powerful metric if you can estimate it. A good rule of thumb is: (number of people minus hours, times average hourly rate) plus (cost of assets and services required).

    Aim to use three to five metrics to prove your case. You don’t want to overwhelm with data. The point is to show that things are better with CI/CD, not that you’ve gathered a lot of numbers. Use a simple before-and-after format to show the change. State the changes in terms of increased value, reduced cost and/or reduced risk. For example, “We increased value for our users by shipping 10 times more features in the same time frame, reduced deployment costs by 80% and reduced risk by increasing code coverage by 30 points from 40% to 70%.” 

    Couple Your Efforts to Business Outcomes

    A critical element of IT success is how closely you can partner with the business. It can be next to impossible to get initiatives green-lit if the only benefit is to make things better for IT. But if you can show how some extra effort spent on IT modernization can drive results for the business, then you’ll find you start getting enthusiastic approval from leadership.

    Collaborating with people outside of IT or software R&D is a career-enhancing skill every technical practitioner should strive to improve. 

    Get to know what efforts in sales, marketing and product are dependent on IT. For example, the sales department may desperately need additional capabilities in their forecasting tool if they are going to execute strategic deal acceleration, ensure quarterly numbers are consistent and avoid unpredictability with shareholders. In other words, the fact that your slow delivery cycle can’t get those new features on the release calendar for another three months is putting the stock price in jeopardy.

    To avoid this tragedy, you can tie your CI/CD efforts to the sales outcomes. By getting to know the pain points of your sales colleagues, you can craft a powerhouse “ask” to leadership. “We’d like implement CI/CD to automate deployments for our sales data management system. This will allow us to implement new filters in a matter of days rather than months which sales needs to hit their numbers.” 

    Pulling It All Together 

    It can be demoralizing to feel like you are behind the curve. Looking at other businesses who have already adopted CI/CD it can feel like you might never catch up. If this is the case, some axioms are appropriate, such as the famous Chinese proverb from the Tao Te Ching “A journey of a thousand miles begins with a single step.” And as Theodore Roosevelt said, “Comparison is the thief of joy.”

    The reality is that you are not alone. Many organizations, especially large enterprises, are relying on outdated software practices. Convincing leadership to green-light IT modernization efforts can be a challenge. Adopting CI/CD in a meaningful way does require significant investment, but there is a lot you can do to smooth the path for them and earn their support.

    Begin by identifying a small adventurous team who can serve as an experimental testing grounds. Not only will their success help to convince leadership, but their example serves to light the way for other teams to adopt DevOps. Identify metrics you want to capture and be sure to instrument so you can measure the improvement. Pick a few metrics that show increase in value, decrease in cost and decrease in risk. Finally, reach across the org to collaborate with your non-engineering peers. By showing how your modernization effort drives outcomes for the business you’ll be sure to earn respect as well as additional budget to expand your CI/CD efforts.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — William Chia

  • DevOps Chats: Continuous Delivery at Airbnb

    DevOps Chats: Continuous Delivery at Airbnb

    Spinnaker Summit 2019 Preview: Airbnb is rapidly moving from a monolith Ruby on Rails application to a distributed SOA/Kubernetes architecture in Kubernetes. The new architecture uses self-service codified pipelines and easy webhook integrations, scale adoption and collaboration across the company. Even though continuous integration isn’t new to Airbnb, every team now needs to be able to scale CI across 100’s of containerized services in AWS EC2.

    Software Engineer Brian Wolfe co-led the decision to move to Spinnaker and build in more automation. At one year into the project, Airbnb has 40 services in production with many more to follow.

    This episode of DevOps Chats features a preview of Brian’s talk, “Scaling a Migration to Continuous Delivery (Airbnb)”. Brian’s talk is on Saturday, November 16 11:00 am, at Spinnaker Summit 2019 in San Diego.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today I’m joined by Brian Wolfe, who is a software engineer at Airbnb. Our topic is a talk that he’s gonna be delivering at Spinnaker Summit 2019 in San Diego. The topic of that talk is scaling of migration to continuous delivery. Continuous delivery is a hot topic right now. That’ll be happening on Saturday, November 16th at 11:00 a.m.

    Brian, welcome to DevOps Chat.

    Brian Wolfe: Thanks so much, Mitch. It’s really an honor to be talking with you today, so.

    Ashley: Well I’m more honored to have you on. I appreciate you taking the time. Tell us a little bit about you. Introduce yourself, tell us what you do and a little bit about–I think we know Airbnb–but tell us about what part in Airbnb that you work in.

    Wolfe: Cool. Yeah, so I assume most people who listen to the podcast know what Airbnb is, but we’re a worldwide community of hosts and guests. We bring people together to have really local experiences. I’m gonna skip the rest of that little spiel.

    Ashley: [Laughs]

    Wolfe: But I’ve been at Airbnb for about three-and-a-half years, and most of that time I’ve been kind of on the operational tooling side, and so a lot of that was observability works, so looking at your metrics and traces and logs, and then performance works, so like figure out how to make Airbnb–monitor Airbnb performance, make it faster and that sort of thing. And so but for the last year I’ve been the tech lead on our continuous delivery team, which is kind of an ambitiously named team. We’re not there yet. But the goal of this team was to really up level how we deliver software at Airbnb.

    And so my experience is mostly looking at how we’re making the transition from a monolith which was written in Ruby on Rails to an SOA over the last two years and kind of continuing on into 2020. And part of that is how do we scale how we deliver our software. It used to be a more core team who understood how to scale our monolith. And now every team kind of needs to know how to deliver that software, how to scale it and how to keep it working.

    Ashley: Now, is the move to an SOA, and so we mean service-oriented architecture, correct? Is that what you’re referring to?

    Wolfe: Yeah.

    Ashley: Is the move to that kind of architecture what prompted you to–or order Airbnb to–invest so heavily in this automated continuous delivery? Or was that kind of happening in parallel? Gives a little bit of idea of context of how this kind of came together.

    Wolfe: Yeah, so it definitely happened because of the move to SOA. And if you look at what our processes were before, it was very consolidated. Most people were applying the same code base. And so you kind of could have practices that worked for that one code base. But as we moved to SOA we now have hundreds of services that are being deployed, and you need to be able to scale those best practices across all of those services. And so that requires that you add these automation pieces so that humans can make fewer mistakes.

    Ashley: That makes a lot of sense. I imagine you have a kind of continuous integration happening at the front end of this, right, leading into your continuous delivery?

    Wolfe: Absolutely. So we’ve had continuous integration for a long time. And so all of our unit tests and that sort of thing and all of our builds are happening in continuous integration. That’s been the case for at least three or four years. And we have fairly mature tooling around that. And we actually did a migration to our new platform there fairly recently that containerizes all of our builds and all of our MCI so it kind of runs in a more uniform manner.

    Ashley: Mm-hmm. Is that moving to Kubernetes? Is that the change you’re referencing or something else?

    Wolfe: So even stuff that’s not running in Kubernetes, so as you can imagine Airbnb is about 10 years old, and so we have a lot of technical history. And so some of that stuff is gonna be running on bare EC2 instances, and some of that is running inside Kubernetes at this point. And so along with the move to SOA we’re also migrating to Kubernetes. And that migration is progressing rapidly. But there’s still gonna be a lot of stuff that has to be built on EC2 and running on EC2. But the builds themselves can happen inside containers.

    Ashley: I know we don’t think of Airbnb as something that’s built 10 years ago and evolved over time, right? We think of it as [Crosstalk] – [Laughs].

    Wolfe: Yeah, yeah. It has a surprising amount of history for such a ____ company, you know?

    Ashley: Well it’s an interesting, you know, it’s an interesting situation that you are involved in, because you’re not talking about a monolith application that was built 30 years ago or 20 years ago. It’s something fairly recent, Ruby on Rails, you know? So it’s still a contemporary programming language, something that everybody is familiar with. But even you have to go through your own kind of architectural and now continuous delivery evolution of that technology.

    Wolfe: Absolutely. I think it’s kind of surprising that even at a company that’s ten years old you have what we consider legacy parts of our stack. I think that happens quickly with a field that evolves as rapidly as ours. And if you look at how continuous delivery has evolved in the last ten years, it’s been a pretty big shift.

    One of the big things we’ve seen is, you know, we had a really good solution for deployment if you look in 2013-2014 time frame with our system and deploy board. But if you look at it now, it looks a lot like a really good CI system, like a really good continuous integration system. And the parts around actually having an organized pipeline that automates the deployment out, we don’t really have that in house yet. And so that’s really why we’ve been adopting Spinnaker as a solution.

    Ashley: Interesting. Well tell us a little bit about were you involved in the choice of bringing in Spinnaker? Was that happening while or before you joined Airbnb?

    Wolfe: Mm-hmm. So the decision for adopting Spinnaker happened last year. And so it was a discussion between myself, my manager and then Jing Jing and Jens, who are on the team. And it was largely about do we want to keep investing in deploy board, which was our existing solution. It was deeply integrated with all of Airbnb stack. Had a lot of stuff in it for how we deploy MonoRail, which is our big Ruby on Rails application.

    Now, do we want to build automation into that, or do we want to bring in something new? And so we did a big research project to look at what are all the available options out there, and what would those give us, and how could we make those work at Airbnb. And at the end of that we decided that we should not invest more in our internal solution and should instead bring in Spinnaker and customize that to kind of encode Airbnb opinions into that via extensions and then use that as our platform for deployment moving forward.

    So we’re still early days in that. We’re about one year in. We have about 40 services onboarded right now. These will be all production services, some of the really critical services out of Airbnb. But considering we have thousands of services at Airbnb, there’s some work to do to kind of make it the standard across.

    Ashley: Mm-hmm. Excellent. Well interesting. Tell us some more about I know in the description of your talk, you talk about that you’re gonna discuss how self-service codified pipelines and easy web hook integrations help you scale adoption and collaboration across the company. Tell us some more about what that is.

    Wolfe: Yeah, so one of the really harder parts about working at a company that’s growing as fast as Airbnb is its really hard to match the needs of everyone. And so you want to make everything self-service if you can so that, you know, I’m creating a standard pipeline that you know I deploy one thing, I do some AB comparison, I roll it out to my next environment, I do another maybe canary analysis rollout, and so on.

    So I can come up with standard components that people can use. But then you have stuff that people have built over time. And so our research team has regression detection that is really specific to them. And they think it provides really high signal if some functionality regression has occurred because you have things like search ranking and the actual layout of the results in the response package, and you need to make sure those things don’t change if you don’t intend them to change.

    And so they built a service to actually do that regression detection, and they want to integrate that with their deployed pipeline. And they want that to just be something that automatically happens every time that they run a deploy. You deploy to staging, you call this service with some arguments, you wait for that regression test to pass, and then if it fails you present some custom UI that says, “Okay, this is what failed. This is why. And this is how you can go learn about it some more.” And you move onto the next stage or you fail the pipeline and figure out what’s going on.

    What we wanted to do is make it really easy for teams to plug in services like this, ‘cause they do provide the most value. The way we’re doing that is by integrating, actually, with our interface definition language that we use internally. And so we actually extend Spinnaker to just provide a little web hook stage that people can reuse and call out to their services. But then they get a nice user interface on top of that. And so they can kind of provide just a base level of functionality within Spinnaker. And it’s kind of a minimal amount of work for us to onboard a new type of stage. Does that kind of make sense?

    Ashley: Yeah. I was just gonna ask you about that. Sometimes it can be a real challenge to introduce such a fundamental tool, like this is fundamental to your software development and delivery process and what kind of things that you can do to minimize the disruption, lower the bar in the area of entry for the teams. And a lot of it depends, too, on how much your organization does software process similarly, or is it very decentralized and everybody kind of does their own thing. It’s such an application if it’s been in a monolith kind of state. I imagine there’s a lot more similarities in how people work at Airbnb. But you’ve gotta still figure out how do you make this easy, right?

    Wolfe: Yeah. So I think we’re lucky in the sense that right now there’s really one deployment tool that people use, and that’s deploy board. And now we’ve introduced a second deployment tool. And our strategy here is actually we make the experience when you’re first onboarding actually look a lot like deploy board.

    And so Spinnaker lets you customize the user interface. And so we actually have a panel within Spinnaker that shows a view that actually looks really similar to the view that you get in our old tool. But then it provides all this power under the hood when you actually start your deploy. And so that’s been pretty valuable for us for onboarding because it doesn’t look that dissimilar, I would say a little rough around the edges, to be honest still.

    It’s, you know, we spent a lot of time optimizing that flow for deploy board. People get a little bit confused sometimes. But just having that initial experience look similar has made onboarding a lot easier. When we first proposed using Spinnaker, people were like, “I can’t figure out what’s going on in the UI. I don’t know what I’m doing here. What are you guys thinking?” But just by providing that similar viewpoint people are like, “Oh, I know what to do. I’ll just click on this button, which looks the same as we saw before, and that should start my deploy doing the right thing.”

    Ashley: You know, never underestimate the value of an easy-to-use user interface or process or whatever.

    Wolfe: Especially just having that familiarity, I think, it’s–Jens on my team has been a continual advocate for really pushing on, like, make this easy to transition from our old tool to our new tool. And I would say that there are some usability gaps that we’ve had to come across. But they’re getting better, I would say.

    Ashley: How far along in the rollout process of this are you? Are you in the still kind of beginning third of it, working with some of the early teams that are adopting? Are you now moving into more broader adoption of it? Where are you kind of in that process, that maturation process?

    Wolfe: Yeah, so we’re kind of in the–we’re calling it a beta stage. So in alpha stage we were really hitting some early adopters, people who were willing to take some risks. Now we’re onboarding kind of the big customers, the ones who are pretty demanding and making sure that this actually works for them. And so what we’re doing is we’re measuring how much do we prevent, and so how many rollbacks are we preventing, how many incidents are we preventing, and making sure that Spinnaker, as the platform we’re currently providing, is actually delivering business value.

    We’re limiting our onboarding throughout 2019 to about 50 teams. And at the end of 2019 we’ll have a really good idea of what works and what doesn’t. And in 2020 we’re going to open up the adoption to the full company. Kind of at the same time we’re going through a lot of scaling exercises to make sure that we will actually be able to scale to the full company.

    Ashley: And give us an idea of the 50 teams, what are usually the size of those teams? What do they range?

    Wolfe: Yeah, so the smallest teams will be probably about six or seven developers deploying a service. The largest team that we have onboarded has about 45 developers. And then we’re aiming for one of our front-end services, which is more monolithic, and so that’ll have several hundred developers working on it. But then there’s kind of an operational expert team that manages what that deployment looks like.

    Ashley: Mm-hmm. Well that’s a pretty good range in different sizes of teams. So I’m sure–and parts of the application–so I assume they bring different challenges with them. How do you measure success from your decision of both going down the path of implementing continuous delivery and Spinnaker? You talked about business value. You also talked about preventing how many rollbacks and incidents that also happened. But how do you demonstrate to the people that said we’re gonna spend this money having you go implement this, and tell them that it was worth it?

    Wolfe: Totally. That is a great question. And so one of the big motivators for us was actually for regression prevention. There are kind of two aspects for CD. One of them is increased productivity for developers. And then another one is having more vigorous processes for rollout. And we were definitely focused on the vigorous processes for rollout and having automated canary analysis by default for every service. And so that’s kind of the route that we’re pursuing, really, in 2019 in terms of proving the business value.

    Ashley: Mm-hmm.

    Wolfe: In 2020 we’re gonna have more metrics and more ability to say something around how productive we have made our engineers, or at least that we haven’t made the story harder. But right now it’s proven a little bit harder to quantify that. So we get people saying, “Yeah, we love it. We love that we can kind of ignore the deploy process now.” But aside from having a CSAT style score where you’re just saying, you know, rate how productive you are on a scale of one to ten, it’s been pretty hard to quantify the productivity gains we’ve seen with Spinnaker.

    Ashley: Well, that is often a challenge, right, for us in the software world in implementing technology, and as you’ve talked about some of the regression testing issues, maybe even incidents in the old process compared to the new, hopefully there are some metrics you can also use from the old methods to the new and to give you some places to start, at least, to benchmark those things.

    Wolfe: Certainly for regression detection we have. We have strong evidence that automating this pipeline–and so what I really think of Spinnaker as is a way to automate your run book. Just the fact that it is automated now has reduced the number of regressions that have gotten out to production. We have very strong evidence of that at this point.

    Ashley: Well and hopefully you can sing some of the praises, the good things of what the teams have learned so far with folks that are adopting it as you take on some of the bigger challenges like the larger teams do.

    Well now, I appreciate you coming on the podcast. It’s been fascinating learning about what you’re gonna talk about. And I wish you the best in your presentation at Spinnaker Summit.

    Wolfe: Thanks so much, Mitch. This has been a pleasure. And I hope to meet you at some point soon.

    Ashley: That would be fantastic. I would enjoy that very much. I’d like to thank my guest today, Brian Wolfe, software engineer at Airbnb for sharing with us his experience with Spinnaker and how they are migrating to a continuous delivery model and scaling that up in the organization. Brian’s gonna be talking at the Spinnaker Summit 2019, which is November 15th through the 19th in San Diego. His talk is on Saturday the 16th at 11:00 a.m. And I believe you’re gonna be doing that with Jens Vanderhaeghe? Is that correct?

    Wolfe: Yes, that is correct.

    Ashley: Awesome. Good to have you both up there. Well thank you everyone for joining us today. I’d like to thank our listeners for taking the time to check out the podcast and hear about this talk. This is Mitch Ashley with devopsy.kinsta.cloud. And you have listened to another DevOps Chat with my guest. Be careful out there.

    — Mitchell Ashley

  • When Should You Go for Microservice Architecture?

    When Should You Go for Microservice Architecture?

    There is steady increase in the adoption of microservice architecture style since 2014 (Figure 1). Microservice architectural style structures an application as a collection of loosely coupled services that implement business capabilities.

    An architecture style is a family of architectures that share certain characteristics. For example, N-tier is a common architecture style. Architecture styles generally don’t dictate the use of particular technologies, but some technologies are well-suited for certain architectures. For example, containers are well suited for microservice since they go hand-in-hand for the deployment.

    In this article, you will learn about the typical considerations, challenges and benefits of the microservice architecture style.

    Figure 1: Microservice Google Trends.

    While microservice applications are built as a set of modular components, they are easier to understand, simpler to test and effortless to maintain over the life of the application. It enables organizations to achieve agility and be able to improve the time it takes to get working enhancements to production.

    It also enables the continuous delivery/deployment of large, complex applications and the evolution of its technology stack. Having detailed out on the benefits side there are quite a bit of challenges as well, which we will discuss in the next section.

    Constraints Imposed by Microservice Style

    By adhering to the following constraints imposed by microservice architecture style, what we get is a system where services can be deployed independently, faults are isolated, frequent updates are possible and it’s easy to introduce new technologies into the application.

    • Each service represents a single responsibility.
    • Every service is independent of the others.
    • Each service needs its own JVM (or equivalent) so instances are isolated.
    • Data is private to the service that owns it.
    • Services do not share data and need to implement queries that need to retrieve data owned by multiple services.
    • Well defined mechanism to implement service-to-service communication and scheme to deal with partial failure.
    • Requests that span multiple services and require careful coordination between the teams.
    • Testing to cover the interactions between services.
    • Deploying and managing a system comprised of many different services.

    Consider Challenges Versus Benefits

    Each architectural constraint has its own associated challenges/benefits, so it’s important to understand and balance both. Before adopting any style of architecture, you have to ask yourself if the benefits outweigh the challenges for the application you are considering.

    In the table below, we take a look at the benefits versus challenges of microservice style applications.

    Benefits Challenges
    Enables the continuous delivery and deployment of large, complex applications. There is an additional complexity of creating a distributed system.
    Improved maintainability: Each service is relatively small so it’s easier to understand and change. Implementing requests that span multiple services is more difficult.

    Maintaining data consistency between service(s) is a challenge.
    Better Testability: services are smaller and faster to test. Testing the interactions between services is more difficult.
    Better deployability: services can be deployed independently. Increased operational and deployment complexity of deploying and managing a system comprised of many different services.
    Each team can develop, test, deploy and scale their services independently of all of the other teams. Implementing requests that span multiple services requires careful coordination between the teams.
    Improved fault isolation. Inter-service communication and dealing with partial failure implementation is challenging.
    Eliminates long-term commitment to a technology stack. Overhead of multiple JVM runtimes (or equivalent) and increase in memory consumption needs to be taken care of.

    Scenarios Where You Can Consider Going for Microservice

    Consider an scenario where you are developing an enterprise application that must support the following characteristics:

    • Support for different variety of clients that includes desktop browsers, mobile browsers and native mobile applications.
    • Expose an API for third parties to consume.
    • Integration with other applications via web services or a message broker.
    • Run multiple instances of the application on multiple machines to fulfill scalability and availability NFR requirements.
    • Adopt emerging technology stack.
    • Planning to go for continuous deployment pipeline setup for the application.

    From the requirements above, you can very well say the application is 100% fit for a microservices architecture.

    You have to define an architecture that structures the application as a set of loosely coupled, collaborating services. Services can communicate using either synchronous or asynchronous protocols. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services.

    Let’s look at some of the typical scenarios where you can consider going for microservice style of architecture:

    1. Monolithic application migration due to improvements needed in scalability, manageability, agility or speed of delivery.
    2. Re-platform a legacy application by transforming functions/modules to microservices.
    3. Rewriting legacy application to modern languages, technology stack to meet the demands of modern business.
    4. Individual cross-cutting services that are independent in nature. For example: encryption services, authentication services, etc.
    5. Independent business applications or services reused across multiple channels. For example, payment services, login services, flight search services, customer profile services, notification services, etc.
    6. Commonly used enterprise applications. For example, time tracking application.
    7. Scenarios where a service provider makes computing resources and infrastructure management available to the customer as needed. For example, forecasting services, price calculation services, prediction services, etc.
    8. Back-end services for responsive client-side web application where data could be coming from multiple channels or different data sources.
    9. Highly agile applications or applications demanding speed of delivery or time to market or innovation pilots, etc.
    10. Applications that got polyglot, multi-language, cloud application development.

    Make the Choice

    Before going for microservice architecture, make sure you know the challenges and benefits. Otherwise, your application design could end up with a design that fits the style but does not achieve its full potential. Adopt microservices only if you see enough value for your applications. Also note sometimes relaxing a constraint is better than insisting on architectural purity.

    — Karthikeyan Shanmugam

  • DevOps Chat: 2019 Accelerate Report with Dr. Nicole Forsgren

    DevOps Chat: 2019 Accelerate Report with Dr. Nicole Forsgren

    There are many interviews you do as part of the role as editor in chief of devopsy.kinsta.cloud. Then there are some that make it all worthwhile. Anytime I have the pleasure of speaking with Dr. Nicole Forsgren, it makes all of the other things I do worthwhile. She has a clarity of vision borne from the foundation of verifiable metrics she has measured and surveyed over the last six years.

    Just about every DevOps presentation you will see has some reference to her Accelerate State of DevOps Report. And for good reason. It has become the “authority” on DevOps metrics.

    We sat down with Nicole to go over what she thinks are some of the key findings in this years report. Have a listen and enjoy.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Lucky you, folks out there, because you’re catching I think what will be one of the best chats of the year. I’m joined by my good friend and DevOps survey expert, guru—just all around great person, Dr. Nicole Forsgren. Nicole, welcome.

    Nicole Forsgren: Hey, thanks for having me.

    Shimel: It’s my pleasure to have you on, Nicole, and you know I always get excited to have you on our show. But Nicole, double whammy reason to be excited in that the survey is out. I know you put your heart, soul and guts into this thing for 10 months a year or so and, you know, between drawing up the questions, getting the responses, analyzing them, doing the report, then talking about the report, it is—it’s a lot of work. I don’t know if people at home realize exactly how much.

    Forsgren: I know, I know. Every year, it’s so much, and every once in a while, I’m like, “No more!” So, I have one week where it’s just crazy and I’m like, “I’m not doing it again!” And two days after release, I’m like, “This is my favorite time of year! It’s the best!” [Laughter]

    Shimel: [Laughter] Absolutely. And, you know, just for folks out there who, I don’t know, maybe they’re not familiar or they are familiar but they don’t know the whole story—you’ve been involved in the State of DevOps Report now, is it six years?

    Forsgren: Yeah! This is six years. I’ve been lead investigator on the report. So, it’s the State of DevOps Reports. It’s the longest running, largest, academically rigorous research into DevOps. And so, when we say DevOps, we’re talking about developing and delivering software with speed and stability, in ways that drive business outcomes and the capabilities and practices that are impactful. And when I say impactful, I mean things that are statistically significant.

    So, when people say, you know, “Does this make a difference? Does CI actually matter? What type of automation is important? Do we care about trunk based development? Everyone says culture is important—does culture matter, and what type of culture?” These are the types of things we’ve been researching for six years now. And it’s—when I say it’s a huge study, we’ve hit over 31,000 data points now.

    And—I keep talking, I’m so excited [Laughter]—

    Shimel: No, no—go.

    Forsgren: —academically rigorous. When I started doing this, I was a professor. So, this has been written up in academic peer review, but because we want to make an impact in industry and because we want everyone to be able to read it and access it and understand it, we translate it, right? We make it accessible.

    So, we put it out in the State of DevOps Report. So, I sometimes joke it’s like an adult picture book. It’s larger font, it’s big print, it’s graphs, it’s charts. We do layout really carefully so that if you want, you know, some people print it out and they put it on the wall. You can screenshot it so you can put it in slide decks.

    And I also keep saying “we.” So, historically, the DORA authors have been myself, Jez Humble, Gene Kim. The authors this year are myself, Dustin Smith—he’s a new researcher who joined me, he’s with the team at Google Cloud—Jez Humble and then this year, we were also joined by Jesse Frizzell.

    Shimel: Yes, absolutely. We ran—we covered that on devopsy.kinsta.cloud, actually, I remember.

    Forsgren: Yes!

    Shimel: A couple things—and, you know, you guys did the research here, but let’s be clear. You could go to any DevOps event the world over—and I do mean the whole world over—

    Forsgren: Yep.

    Shimel: And listen to a presentation and, you know, nine out of 10 dentists agree, nine out of 10 presentations will have some metric from this survey that they use to cite as authority on where we are in DevOps, what is the state of CI/CD, et cetera, et cetera. So, it really is—

    Forsgren: So, it comes out of the survey, or it comes—

    Shimel: From [Cross talk].

    Forsgren: Okay, Accelerate, and it comes out of—so, like you said, it could reference a DevOps event or an agile event or a testing event. Because we do tend to cover so many things and we do cover them in a very, very rigorous way, right? So, it’s not—you know, the joke is “lies, damn lies, and statistics,” right?

    Shimel: Yep.

    Forsgren: We do cover it in a very rigorous way, and we put it forward in the finding, the things that we find, and we say, “This is what we find and these are some of the limitations, and these are the evaluative criteria,” right? Like, it does not include—like, this is not a typical vendor report, right? Like, we don’t—

    Shimel: Right, and that’s important.

    Forsgren: We don’t talk about tools. And why don’t we talk about tools? Some people are like, “Well, what tool should I use?” I’m like, “I don’t know, what tool should you use?” Like, for example, CI. CI is predictive of better continuous delivery and better speed and stability.

    Now, when you do CI, it should—every time you check in code, it should result in an automatic build of the software. It should trigger automated tests. You should get results of your automated build and tests at least every day, and your developers should see that at least every day.

    So, here’s your four evaluative criteria. Now, whatever tools you wanna use to do your CI, look at those four pieces. Now, I don’t run through a set of tools because there’s a million tools, and what happens when your tool comes out with a new release? It could change your, I mean—

    Shimel: Well, not only that. I mean—

    Forsgren: So many things.

    Shimel: You wanna know, Nicole, I’m on the other side, right? I’m running this devopsy.kinsta.cloud, we’re media. We do cover tools. It’s a little—it dirties the water. It muddies the water. Because then right away, people wanna know what’s your bias, who’s sponsoring, you know what I mean?

    Forsgren: Right.

    Shimel: I just, I kinda like it better this—and I think most people do. We’re not looking for you to pick one tool or, this isn’t a magic quadrant nonsense kind of thing.

    Forsgren: Well, and this way, I don’t have to keep up with toolset changes or feature set changes or versioning changes.

    Shimel: Or who bought who and—yeah, all of that stuff.

    Forsgren: Yep. Anyone can take those evaluative criteria, they can apply it to whatever tool they wanna use. Heck, vendors can use it. They can say, “If I’m building a tool, this is what I should be looking at.”

    Shimel: Absolutely, absolutely. Let’s talk, you mentioned lies, damn lies, statistics, math.

    Forsgren: [Laughter] So much math.

    Shimel: You know what, let’s dig in on that a second, because—so, first of all, obviously, you’re a woman, right? And it’s great, we have a woman here talking math and—

    Forsgren: Yeah.

    Shimel: —for my audience out there, you know what, you can grow up and be Nicole, too.

    Forsgren: Uh huh.

    Shimel: So, it’s encouraging. But too many people, Nicole, they see big numbers—and I don’t know if it’s the law of big numbers or what, but their eyes glaze over.

    Forsgren: Yep.

    Shimel: And they won’t recognize something that’s kind of as plain as the nose on their face, right? So, let’s get some of these highlights. Thirty one thousand plus respondents over the last six years.

    Forsgren: Yep.

    Shimel: That’s huge! I mean, that’s a big pool, right?

    Forsgren: We’ve got a lot of data points around the world, all industries. So, it’s helps our data to be more generalizable. So, that’s kind of a research word. What that means is, it means that there’s a high likelihood that any of our findings will work for you—which is important to me, because I used to be an engineer. I also was a consultant for a few years. And so often, I would come forward with a proposal for a solution, and if it sounded hard, many times, my manager or the lead on the project would say, “Oh, well, that won’t work here. That only worked on that other team.” Well, if my results are generalizable, that means it has a high likelihood of working in any team.

    Shimel: Absolutely.

    Forsgren: Yep.

    Shimel: Let me throw some more numbers out at you.

    Forsgren: Yep.

    Shimel: Normalized annual deployments range from 1,460 deploys a year for high performance down to seven for low performers, right? Seven deploys per year for low performers. Elite performers deploy code 208 times more frequently than low performers, according to the report.

    And here’s another one, and from my mind, and I’ll ask you—probably one of the most thought provoking, controversial kind of stats in the report. And that is that 20% of respondents consider their organizations to be elite DevOps performers, up from 7% just last year, right?

    Now, guys—don’t get hung up on the math, here. Look at those numbers. They clearly say something, right—1,460 deploys per year is roughly four a day, right That’s what high performers are doing, four a day. Seven a year, maybe a little under two a quarter, right? This isn’t calculus, okay? This is plain arithmetic.

    Nicole, what about that 20% number, though?

    Forsgren: So, that’s interesting. Let me take it back just a step.

    Shimel: Okay.

    Forsgren: When we asked people—so, how did we come up with this classification of low, medium, high, elite performers? I asked people four questions about how they’re developing and delivering software, what the outcome is, right? And so, I say, “How often do you push code?” Right?

    And the nice thing about that question is, almost everyone can answer it at a very high level. “Can you push code on demand?” Right? “Can you do it when you want to?” So, that’s kind of deploying on demand, multiple per day-ish. “Can you do it on demand? Do you do it about, between once a week—between once a week and once a month?” Sometimes people are like, “That’s a really rough number.” And I’m like, “Yeah, it’s a rough number, but pretty much anyone can answer that. Are you between once a week and once a month?”

    Shimel: Right.

    Forsgren: You know, notice this is—for people who are kinda into math, this is a log scale. What I mean by log scale is, it’s increasing in big pieces. On demand between once a day and once a week, between once a week and once per month, between once a month and once per six months, right?

    Shimel: Yep.

    Forsgren: These are getting bigger in big chunks.

    Shimel: Yeah.

    Forsgren: Which is nice, because it gives me pretty good reliability. I’m not asking for, “Are you deploying between one minute and two minutes, between two minutes and three minutes?” People aren’t good at that. Systems are good at that, people are not. So, I’m asking in big pieces.

    Shimel: Yeah, these are big buckets.

    Forsgren: Yeah, these are—and they’re large, increasing buckets.

    Shimel: Yes, agreed.

    Forsgren: Okay, yeah. Okay, so then lead time for changes—that’s the next question I ask. “How long does it take to get from I commit code to code runs in production?” Same type of buckets. It takes less than a day, it takes between a day and a week, it takes between a week and a month, it takes one to six months. People can about answer that question.

    Okay, then I have two stability related questions. When something’s broken or when something needs attention, how long does it take to fix? Less than an hour, less than a day, less than a week, between one and six months? Same types of buckets, right?

    Now, change/fail rate. When we introduce something to production, what’s the likelihood that something goes wrong? Now, these buckets are basically like, we put into about six buckets, right? So, like, 0% to 15%, 15 to 30, right, 30 to 45, 56 to 60. And people can generally bucket that in their heads.

    Then what we do is, I take those four numbers and I throw it into the stats hopper, the stats bucket. And then I—it’s actually called a cluster analysis, because we wanna see how they cluster. So, for people who answer those four questions, I say, “How does those four questions, at the team level”—this is not at the organization level. Because why? Let’s think about organizations. Organizations have teams that operate at very different levels, right?

    Shimel: Mm-hmm.

    Forsgren: If we think about, especially big organizations, you have some teams that are super, super fast, and you have some teams that are kind of on the struggle bus. Which is fine, because we do things differently.

    So, I analyze this at the team level, and the we say, “Okay, how do these four things fall out?” And it’s important to investigate this, because for a long time, for decades, a couple decades, we were always told that in order to be stable, we had to slow down, right? So, remember I said, we had the speed metrics—how often do you deploy, ____ changes? Those are speed, those are throughput. And then we had stability, which is time to restore and what’s your change/fail rate.

    Now, here’s the interesting thing—for six years in a row now, those four things have always clustered together. They’ve always grouped together. Now, occasionally, I have people say, “You’re mistaking correlation for causation.” This is not correlation, this is not causation. We are observing in the data, no one—there are no trade-offs. Those things always group together. They are always clustering together.

    Shimel: Yep.

    Forsgren: For six years in a row. Now, you also commented on—now, how do we get there? Everyone put a pin in that in your head—how do you get to better speed and stability together? Or, conversely, how do you suck at all the things at the same time? Okay, we’ll get there.

    But, now, you noted—and this is super interesting and super important—we went from 7 percent of people being amazing at optimizing and speed and stability to 20 percent. That’s an almost tripling. Now, some people are saying, “How are they elite performers? I don’t see 20 percent of people being elite.” Now, this is a definitional thing. This is very much a research definitional thing. This doesn’t mean that—this is me also being a very nice mother. Like, I love all of my children. Everyone is—I love everyone equally. All of my children are special, right?

    Shimel: Equally. Right. [Laughter]

    Forsgren: Not everyone is going to be a Netflix type of, you know—

    Shimel: Organization.

    Forsgren: —deploying a thousand times a day. Remember, that definition of elite was, you can deploy on demand, multiple times a day. It could be two or three or four times a day, which was how we did the math, because we were like, “We’re gonna be conservative. We’ll call it four times a day.” And I say this in the report, I randomly picked a number, I said four. Four seems reasonable. Some of these companies are deploying thousands of times a day. I picked four instead of five.

    Shimel: Look, I personally think four times a day is amazing, if you’re deploying four times a day—

    Forsgren: Yeah, oh, that seems amazing. But some companies are doing thousands, okay? So, when I say elite, I’m not saying elite is thousands, I’m saying on demand and four seems fine. Making time for changes, it’s less than a day. I didn’t say it had to be 10 seconds, right? But that is also my upper limit, because of how I’m collecting my data. I’m not collecting my data from systems, I’m not saying that elite is 5 seconds versus 10 seconds, because I cannot ask a person, right—

    Shimel: And who is—right, you’ll never be able to measure that.

    Forsgren:—or I can’t ask a person five seconds versus 10 seconds. I can only ask—less than a day.

    Shimel: But let’s put that in context.

    Forsgren: Yep.

    Shimel: So, elite performers do it in less than a day. Low performers are something like 2,500 hours.

    Forsgren: Yes, low performers are between one month and six months. This is still a huge—

    Shimel: You’re talking a day—so, we don’t need computer precision to the millisecond.

    Forsgren: Nope, nope, nope.

    Shimel: We’re talking a day versus months.

    Forsgren: Months.

    Shimel: And people, you don’t have to be a genius to see the difference there.

    Forsgren: Exactly. And the great thing is that this is absolutely achievable. And think about what this means for your companies. If you go from deploying code two, three times a year to being able to push code in less than a day and every single day? Some people are like, “Oh, I don’t need to push features that often to my customers.” That’s great, but you know what you probably do need to do is keep up with compliance and regulatory changes.

    Shimel: Yep.

    Forsgren: You need to keep up with security threats. You need to keep up with infrastructure. This allows you to pivot any time you need to pivot. This allows you to keep up with so many things in your environment.

    I gave a great talk at Black Hat with Kelly Shortridge, and she pointed out that one of the best things you can do to be a pain in the butt for security is to re-roll your infrastructure. Because every time you re-roll a container or re-roll your IP is—an attacker has to completely start over from scratch, now.

    Shimel: Yeah.

    Forsgren: This is so smart, and so good.

    Shimel: Well, and that was one of the great things about immutable infrastructure, right?

    Forsgren: Exactly!

    Shimel: Is, you can absolutely just start from, let them start back—you know, pull the rug out from under the hacker. I mean, but it’s such a—these numbers, like you said, you see these clusters always come together.

    Forsgren: Yep, yep.

    Shimel: They always follow each other. So, time to remediation, right, becomes such a huge thing. Failure rates drop through the floor when you start doing this.

    Forsgren: Yep.

    Shimel: You know—

    Forsgren: And I love that you point out, when we compare the high and the low performers, our speed metrics, our elite performers are 208 times—they’re seeing 208 times more frequent code deployments. They’re 106 times faster, code commit to deploy. The stability metrics are hug. The elite performers are over 2,600 times faster recovering from incidents. And they see seven times lower change/fail rate. This—this is huge.

    Shimel: The numbers are real. Can I throw one other thing at you?

    Forsgren: Yeah, yeah, of course.

    Shimel: These people who tell you, “Our customers don’t care if we update frequently, it’s not important”—I used to believe them, Nicole. But I’ve come to the conclusion that they’re full of crap. That’s arrogant elitism at its worst, and if you don’t think your customers want you to stay on top of things and be current and constantly improving—show me who you are, because I can’t wait to disrupt you and take your customers from you.

    Forsgren: Well, and it’s interesting—

    Shimel: But I don’t buy that any more.

    Forsgren: I have spoken with one or two government and military contractors who have said, “We live in a different space. I do not have a customer”—

    Shimel: Yes, they do.

    Forsgren: Well, and they have said, “I have a customer that doesn’t require a feature change.” And I’ve said [Cross talk]—

    Shimel: No, they do. I’ve sold to the military for years.

    Forsgren: Sure, sure.

    Shimel: They want—you know what? And as counterintuitive as it may be, the military—and I’ve sold to all of our armed service divisions as well as the Secretary of Defense at the Pentagon—they, in a lot of ways, lead. Because their requirements are constant. This is why they have things like DISA and they have things like In-Q-Tel that are investing in the next gen.

    Forsgren: Oh, absolutely.

    Shimel: Because their requirements are constantly pushing the envelope.

    Forsgren: Oh, sure. But to that person in particular, I did have someone come up to me after a talk and say, “I actually do not have any competitors. I do not have feature changes.”

    Shimel: No, they do. It’s a single world. [Cross talk]

    Forsgren: Well, but, to him, I said, “Okay, sure, but you do have compliance and regulatory changes, and you do have security changes.”

    Shimel: And you have changing missions.

    Forsgren: Yep.

    Shimel: Their mission changes. They need—so, again, I just, I don’t buy those people. I think that arrogance is misplaced.

    Forsgren: Well, but, it was interesting, because as soon as I pointed out compliance and regulatory and security, he said, “Oh, well, that’s right.”

    Shimel: Oh, yeah, yeah.

    Forsgren: And that’s what we struggle with.

    Shimel: Yep, I agree with you. So, a couple other things, and we’re running low on time, I apologize.

    Forsgren: Yep, yep. [Laughter]

    Shimel: We could go all day. So, you know, this is the first year that it was Google Cloud involved. Well, Google Cloud was a major sponsor last year.

    Forsgren: Yep, we collaborated with them this year—or last year, and then this is the first year that we’ve joined Google Cloud.

    Shimel: So, let’s talk about what they brought to the party.

    Forsgren: So, they were just a wonderful partner this year. What I really appreciated about working with them this year is, they still allowed me full research independence, and it was fantastic to work with them.

    Shimel: Yeah. Well, and it also seems like they’ve brought, they’ve given you the ability to add more resources, perhaps, to the whole process.

    Forsgren: Yeah. I really loved being able to work and collaborate with Dustin Smith this year. He brought a fantastic eye for research and analysis this year. He has a phenomenal, phenomenal statistics background. And it was almost like being back in academia again where I could have another academic—he has a Ph.D.

    Shimel: Collaborator.

    Forsgren: Yeah! So, I had, like, a full academic peer where I used to be able, when I was a professor, to walk next door and bounce ideas off of someone and have someone replicate every single one of my analyses.

    Now, in the past, I used to pull former Ph.D. students to replicate a handful of my findings. But, as a tiny startup, you’re real scrappy.

    Shimel: Yeah.

    Forsgren: This year, I had Dustin, and he replicated every single one of my findings, and then he came up with new ideas, and we could really spitball off of each other and we had full peer review on every single one of our analyses. It was, like, it was just this academic research dream. It was wonderful.

    Shimel: No, it’s great. I mean, but this is, for entrepreneurs out there, for people in startups listening to this, this is one of the great things about when you do do a merger or acquisition or whatever. The idea that you now have peers—

    Forsgren: Yes!

    Shimel: —to bounce around stuff with, to collaborate with. Because, you know, startups, we run lean and mean.

    Forsgren: [Laughter]

    Shimel: But sometimes, it’s—that’s the code word for by yourself. [Laughter]

    Forsgren: Yep, yep. [Laughter]

    Shimel: And so, it’s not as cool. I just wanted to mention, you know, quick commercial—we’re doing The DevOps Experience, that’s coming on, I think it’s October 10th. Nicole, you’re headlining. You’re gonna go into greater detail on this, so if anyone’s listening—

    Forsgren: Yes, yes! And this year, for the first time—so, in years previous, we’ve always investigated performance. How to make software development and delivery both fast and stable. This year, in 2019, for the first time, we also dug into productivity. So, we have two full research models. So, I will be sure to dig into that.

    Shimel: Absolutely. So, you can check that out on DevOpsExperience.io. This is a virtual event, guys, you can watch it from your desktop.

    Secondly, Nicole, I guess the obvious question is—alright, what’s the time frame for next year?

    Forsgren: Oh, well, I need to take a nap first. [Laughter]

    Shimel: Okay. [Laughter]

    Forsgren: But we tend to release the report late August, so I’m guessing that neighborhood, that time frame.

    Shimel: Well, that’ll be the report, but when do we start, when do the next year’s survey questions come out and all of that good stuff?

    Forsgren: So, we usually release the survey and collect data in the March/April time frame.

    Shimel: Yep.

    Forsgren: So, I’m guessing that as well.

    Shimel: So, are you already working on next year’s questions?

    Forsgren: I mean, I’ve got a couple ideas in the back of my head, but research is a very creative process, so I try to take at least a month to just unwind my brain.

    Shimel: Totally [Cross talk].

    Forsgren: Yep, and then—

    Shimel: Well, it’s well deserved.

    Forsgren: Dustin and I and the team will start kind of opening our brains again. Luckily, we will be at DevOps Enterprise Summit, where we’ll be giving a talk, Dustin and I are speaking, and then that’s one of the best places—

    Shimel: And that is October 28th and 29th at the Cosmopolitan in Las Vegas.

    Forsgren: Yep.

    Shimel: And you can get information, I guess, at IT Revolution.

    Forsgren: Yep. And that’s a fantastic opportunity for us to attend talks, speak to everyone who’s really involved in transformation, the wins, the questions, the challenges—that’s where I get so much inspiration. I get all of it, year ‘round. I’ve got, like, my favorite Google Doc where I keep track of ideas. [Laughter] But that’s where I get a lot of the stuff that people don’t necessarily share out in the wild. That’s where I get a lot of my really great research ideas.

    Shimel: We’ll be broadcasting live from there, so you’ll have to come down and do a quick little live interview—

    Forsgren: Yeah, for sure!

    Shimel: —with Digital Anarchist. Very cool. Can’t wait to see you there. So, Nicole, I apologize. I told you this was gonna be 15 minutes and I think we ran 30-something. [Laughter]

    Forsgren: Sorry, everyone!

    Shimel: But it was well worth it, it was well worth it. Hey, we’ll see you on DevOps Experience, I will see you in person at The DevOps Enterprise Summit in Vegas at the end of October, but in the meantime, go take some well-deserved rest time, my friend. You did good.

    Forsgren: Thanks so much.

    Shimel: Thank you. Dr. Nicole Forsgren, Founder, CEO of DORA, part of Google Cloud, our guest on this DevOps Chat. This is Alan Shimel for DevOps Chat, devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: CI/CD Scalability Lessons with CircleCI

    DevOps Chat: CI/CD Scalability Lessons with CircleCI

    The software development tool needs of a two to three person team can be much different than those of a large enterprise. CI/CD is a common approach nearly all software teams establish. But what needs of a larger software organization do you adopt early on and which simply add more complexity than benefit?

    Rob Zuber, CTO of CircleCI, began tackling this problem in the mobile space and then moved to CircleCI to help create what is now a well established SaaS-based CI/CD offering to software teams of all sizes. Join us on this episode of DevOps Chat to take away some valuable CI/CD lessons for your organization.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Rob Zuber, CTO of CircleCI, and our topic is software innovation at scale. Rob, welcome to DevOps Chat.

    Rob Zuber: Thanks so much, Mitch, it’s great to be here. Thanks for having me.

    Ashley: Would you start by introducing yourself, tell us a little bit about what you do and tell us a little bit about CircleCI.

    Zuber: So, I’m Rob, as you said. I’m the CTO here at CircleCI. I’ve been with the company almost five years now, and I’ll talk a little bit about how I got here once I talk a little bit about what CircleCI does. I think that’s probably the right order.

    So, CircleCI, our big focus is helping every software engineering team be better at what they do. So, be better at getting software from their sort of concept and idea to value delivery in the hands of their customers. So, we sit between the collaboration element and the production deployment element by really being the delivery pipeline. So, we help you take your software from the point that you’ve, again, had an idea, started to write, to making sure that works well, making sure everything everybody’s doing is working well in concert and getting that into a production environment where you can start to realize customer or business value confidently, quickly and being ready to move onto the next thing and to drive value for your customers.

    Ashley: So, this is a pretty big space, a lot of folks in it. I mean, people can download Chef or Puppet or Jenkins and—you know, we could go on and on about different tools within sort of that CI/CD pipeline chain.

    But tell us a little bit about where you uniquely fit into the market.

    Zuber: Yeah, so, a lot has changed in the market over the time that I’ve been here, unsurprisingly—not just at CircleCI, but in the market in general. We’ve seen a lot of people come and go, a lot of companies either snapped up into larger organizations, but maybe they weren’t going to be focused, necessarily, on CI/CD standalone or just not reach sort of critical mass as an organization.

    And the market has also shifted, and what we see now is a lot of people trying to maybe add CI and CD as an extension of something that they’re doing, but not treating it as the core business that they focus on. So, that’s the real thing that separates CircleCI is our focus on CI and CD as a core of what we do. Every day when we get up and get to work, that’s what we’re focusing on, and not tying you into—you know, you’re using this CI and CD capability because it’s part of this other package that you maybe want or don’t want, and really being the choice in this space and giving developers the opportunity to pick the best tool that they want in every different part of their flow, if that makes sense.

    Ashley: Let’s peel back the onion a little bit more. I know that—I mean, it’s a very complex process and CI/CD and all the tools you might use, if I understand correctly, you don’t take a “let’s try to be everything to everybody,” but more of a platform approach with workflow and then you can plug in various tools as part of that workflow package and you pack things into orbs for configuration management, et cetera.

    Can you give us a little bit more detail and meat on the bone about that?

    Zuber: Yeah, that’s exactly right. Well, we believe it’s kind of hard to be wrong about this, I guess, that our customers are software developers, right? And so, they are more than happy to create the capabilities they need if we give them the tools to do that. And orbs is one of those such tools.

    So, it’s basically about realizing that many of our customers are very capable, they’re solving very similar problems, and giving the opportunity to share that, to reuse pieces and then to build. Some of those problems that they’re solving are building integrations with best in breed components of things that we don’t necessarily provide, right? So, that might be something like, I guess, anything from vulnerability scanning or connecting into security systems through to how you do integration with your eventual deployment target, right?

    Ashley: Mm-hmm.

    Zuber: And rather than trying to solve all of those problems and say, “Well, you need to deploy,” like, we’ll also build a cloud and you can deploy to that cloud, or we’re also gonna build all of the tools for all of these parts of your system. We basically give you a really central and easy to use pipeline, effectively, or workflow is the term that we use for it, and the ability to plug into that, those capabilities, right? So, by leveraging orbs which our partners build, you know, to get access to their systems, community members have built, and we’ve built, basically to give you access to the richness of the ecosystem, if you will, using that to really tap into those additional systems, but the ease of central management of all that. So, you have great clarity about what’s happening in your delivery process.

    Ashley: And I understand congratulations are in order. Recently, you had your series D, 56 million led by Owl Rock Capital and NextEquity Partners—congratulations.

    Zuber: Thank you very much. Yes, it’s very exciting.

    Ashley: So, with great power comes great responsibility. What are you gonna do with that money? [Laughter]

    Zuber: Yeah, that’s a great question. I mean, honestly, a lot of it is very much continuing on this trajectory, right? Like, we believe in what we’re doing, we believe we’re doing the right things and we have the success to show for it, but in every one of those areas, we can do more, right? So, we’re continuing to invest in engineering and product development, clearly to add capabilities. I mean, part of that is really building around those types of integration models like orbs that we talked about.

    Also, taking one of the key areas that we’ve really had—well, I guess just through our success over the years, because we’ve been around for about eight years as a company—we’re sitting on a lot of deep understanding of how software engineers are building. We have thousands and thousands of customers building tens or hundreds of thousands of projects. And so, we see that, right? We see the flow, we see what works for them, what doesn’t work.

    We see whether they—basically, the rate at which they’re able to deliver software, the kinds of tools they use, how the ecosystem is supporting them or not, and being able to take all of that rich data and turn it back to our customers as value for them to really help them be better. Like, moving away from just a tool—I mean, a great tool, but really, a tool that not only moves your code through, but helps you understand how you could be doing better and where your opportunities are for improvement. Or, honestly, at the other end, it’s always worth mentioning, if you’re doing great and you can invest your time and energy in something else, because things are really stable and working well, right?

    So, that’s a place that we’re making some investment for our product with that perspective, and then again from a, I guess, the extension that we talked about and just investing everywhere that we’re already investing in core CI and CD. I mean, over the time that I’ve been with CircleCI, the entire process of software delivery and how we package and build product has fundamentally changed, and I expect that to continue to happen. I mean, the pace at which we move in this market is a little crazy sometimes.

    And so, we need to continue to evolve to support how software development is getting done in order to be, really, the best tool, as we are today, for software delivery.

    Ashley: And I should know this, probably—are you running the jobs that you’re seeing in the cloud or is a lot of this on prem for customers? How do you get access to that [Cross talk]?

    Zuber: Yes, great question. So, we offer both. We have a cloud platform, which is, the majority of our customers use that, and the majority of the builds that we’re running are on that platform. We do have an on-prem solution as well for very large customers with complex cases or specific needs where they’re interested in deploying the software and operating it themselves.

    Yeah, and so, one thing I was gonna say about that change, and tying it back to kinda orbs and being able to integrate with other systems that we’ve talked about, we’ve been evolving to support the change in the market, but also evolving to have a more flexible platform because we see this constant change, and not wanting to play catch up or try to stay ahead of it all the time, but rather, create more flexible tools that continue to evolve with changes and how people do software development and give our users and our customers the ability to use the platform in ways that they see fit or best meet their needs as we continue to evolve.

    Ashley: That certainly makes sense why you focused around the orb strategy and investing in CLI and APIs. Are you also focusing on onboarding?

    Zuber: Absolutely, yes. So, I think the key to this for everyone is time to value, right? Like, CI and CD can be a complex system—

    Ashley: Mm-hmm, very.

    Zuber: And it depends a little bit on the size of your org. But, as I said, when we talk about those small little companies starting out, I mean, they just want something that works that will get out of their way. And so, it’s that sort of gradual growth with you as a team to meet you where you are.

    So, if you have a simple application and you’re really focused on finding product market fit, then it should take as little effort as possible to get up and running and just make sure that you’re delivering with confidence so you can focus on those iterations of your early—I always talk about it in terms of companies like startups, but it might just be an early project, right, in a larger organization. Those small new projects are a great place to try out new capabilities, new tools, new processes.

    And so, supporting you to get up and going and realizing that value very quickly, but again, as you get to large organizations, you need to be able to roll in more and more capabilities. But getting up and going quickly and really getting those moments where you recognize, “Okay, this is actually changing how I’m working and this is really valuable,” that needs to be very simple, and so, we’re constantly investing in making that as simple for as many different kinds of teams, of projects, code bases, tech stacks, again, as they change, we want to cover as many of those as possible.

    Ashley: You’ve talked about startup companies and startup projects, but I know, also, you focus on enterprises. Those can be very, very different—drastically different in terms of customer requirements, issues, scale that you have to solve. What are some of the challenges that you’ve both run into, encountered, and also feel like you’ve addressed pretty well in those two different communities?

    Zuber: Yeah, that’s exactly right. I mean, I like to think of it as a continuum. I don’t know, maybe that just makes me happier than two really distinct communities, right? And I think that one of the things you see in enterprises that are succeeding is seeing the types of approaches that smaller companies take, right? But, of course, you have to take that and figure out how to make it work at your scale.

    Ashley: Mm-hmm.

    Zuber: To your point, we absolutely have a very large number of very large customers, about a third of the Forbes Cloud 100. So, really large, influential, but I would still say—that particular group, tech forward companies. Meaning, coming from a background where their software development was always central. You mentioned transformations previously, so we also play in a lot of those. But it’s a different space, right, of companies that are trying to reimagine how they build versus companies that have grown to scale, sort of always thinking about software development.

    But many of the challenges are similar, right? Just the pure scale. And so, that scale comes in multiple different forms. It might just be the total volume of jobs that you’re running, and the growth of our cloud platform over the years has been remarkable, and we’re constantly working to figure out what’s the next order of magnitude, the next order of magnitude, how do we continue to support that as we just continue to go through this growth, which is fantastic, but also exciting, I would say, from an engineering perspective.

    Ashley: Mm-hmm.

    Zuber: So, there’s kinda pure scale on just a job perspective, but the things that get more interesting and that we’ve really invested in are, for example, the complexity of workflows, right? So, if you have a lot of different systems that all need to be either validated together or have dependencies that need to be understood as they flow through the CI and CD process, or maybe a large set of validations that you do beyond just testing. So, that might be—again, I mentioned security scans earlier, linting. You know, all of the kinds of gates and processes that get put in place as companies get larger and being able to manage those independently against a very large code base with a large number of contributors.

    Again, that might not be total number of jobs, for example, but the complexity of those definitions scales itself, the number of developers contributing—that scales. And so, orienting the product around those kinds of scaling points has been something that we’ve had to do as our customers have grown, as we’ve brought on large customers where we’ve really invested a lot of time to make sure, particularly in a cloud environment, which is where—there’s an additional layer of value, for sure, for our customers, because they don’t have to think about any of the management, right? They come in with very, very large workflows, and the capacity is all available. And when they’re quiet, they don’t have to worry about additional machines being online or wastage or anything like that, because we’re managing all that for them.

    Ashley: Mm-hmm.

    Zuber: And so, doing that for this large blend of customers, some of whom are quite big and driving a lot of work, is something that we’ve really figured out.

    Ashley: Well, thinking about, you mentioned continuum, which is a great way to think about it, too—why don’t you share with us a couple lessons that you’ve seen customers learn, maybe you’ve learned yourself, running your own product development and software development process. As people go from that continuum of, “I’m just getting involved in CI/CD,” using a product like yours, obviously, there’s great features and stuff, we all know that, that you all have—but what are some of the lessons that they learn as someone goes from, “I’ve got a development team, we’ve just implemented CI/CD,” kinda getting up to this point? The next scale issue that we tend to run into is X and then kinda what happens after that.

    What’s that maturity lifecycle look like?

    Zuber: Yeah, I really like the word maturity that you used there. Because I think that a lot of times, when we think about this, we think about the growth of companies at scale, we spend a lot of time talking about tools. And of course, you know, it’s easy to look at CircleCI and what we do and think about it as a tool. But ultimately, the biggest challenges are gonna be shifts in culture, right? So, process how you think about getting work done, how people interact, definition of roles and responsibilities.

    I mean, everybody starts out in a—well, everybody—when you start a company in this space as a tiny little, maybe you’re like three people, five people, whatever, roles tend to be pretty loose, because everybody’s just trying to get done whatever needs to get done, right? And one day, you’re the DBA and the next day you’re the barista making sure everyone else has enough coffee to get work done, right?

    And as you grow, there’s parts of that that you really wanna keep—absolutely, right? Like, the focus on the mission and being really clear about where you’re trying to get to. But, it becomes more challenging for everybody to do everything, right? You actually need to have some clear boundaries and understanding.

    So, that shift in culture that is like—what are the parts that we keep? Or one of the ways that I often describe it, and we, you know, for our own part, as I said, have gone from about 20 when I joined to 250 and still growing. One of the things that I always look for is what was the intent, and then how do we implement that now at this next level of scale?

    Ashley: Mm-hmm.

    Zuber: And I think that applies to your tooling and your process and everything else as well, right? So, we have always been a very transparent company. And so, transparency when you’re five, 10, 20 people is usually about just kind of making sure everyone knows everything that’s happening. But when you get to 250 people, it’s about really being clear about what’s happening, but being able to define that message and convey it in a way that’s not just this firehose of information or an overload for everyone, right?

    And I’m trying to shift that back to sort of technology and where you were going with this—even though I believe it’s ultimately, it’s these underlying cultural pieces. When I look at people building software, I see, for example, people looking to large organizations—you know, Google, Facebook, Netflix—and saying, “Well, they build software like this, so that must be right.” And again, it’s important to look at the intent, right?

    So, yes, you probably wanna have a CI and CD pipeline, because it’s gonna get a lot of stuff out of your way, but I would guess that when you’re starting out, you probably wanna have a very simple application, because you don’t know yet what your business is, whether you have a business, what the fit is.

    Ashley: [Laughter]

    Zuber: So, this is like, this argues for the monolith, right? Everybody, ultimately—not everybody—many people ultimately say, “You know what? The monolith isn’t scaling with our organization. It doesn’t match our ability to follow our intent. Our intent might be autonomy or ability to work on disparate areas of a product separately, stuff like that.” That works, actually, really well in a monolith at a small size, because you have so much shared understanding.

    Ashley: Right, right.

    Zuber: And at some point, maybe you say, “Okay, this isn’t working any more, we’re gonna start breaking out services”—kind of a natural evolution that many companies go through. But, again, people look at that at the beginning and say, “Oh, well, that’s where we’re gonna end up. Let’s just do it out of the gate” and bring in a lot of overhead and complexity that’s unnecessary for their size, and ultimately end up, I would go so far as to say failing, because they create sort of a technical overhead or burden that’s not in line with where they’re at as a business.

    Ashley: Mm-hmm.

    Zuber: And so, if I were to pull out the underlying lesson in all of that, it’s like—find the intent in what you’re doing and then determine the implementation that’s right for your scale. And then, I guess the other big lesson if you’re going through scale at a high enough rate, recognize where you are on that curve and recognize that it’s changing, right? Because it’s easy to think that things are gonna stay the same and the system that you have is gonna be a great system for a long time.

    But if you’re growing quickly, this applies to your software, it applies to your team structure, to how you manage your organization. You need to be aware of that change.

    Ashley: Yeah, I believe that when we talked about developing software, what organizations are really doing is learning how to create software, and that’s what we—or the team, the organization is in the process of doing, and then there’s that evolution on the maturity curve.

    So, you, whether you’re the QA person, the DevOps person, the developer, the architect, et cetera—it’s about all that function so that you can think of it as running a football play or a soccer play or a baseball play. You’re learning to function and operate as a team to create software. Do you agree, disagree?

    Zuber: Yeah, I think it’s quite on point. And the reason that I think this is really fascinating, I know this is very—speaking of side tangents, my earliest days before I got really into software development, I actually spent in a factory. I was a process engineer. And the great thing about a factory is, we would build tens of thousands of the same thing, every day. And so, refining the process was about refining the process for building the same thing.

    But in software development, you basically never build the same thing twice, right? I mean, you might get hired into another company and someone’s like, “It’s great that you are here, because we need you to build basically the same thing that you already built.” But it’s this constant discovery, right? You’re constantly in a design phase of trying to figure out how do we go about building this thing that we’ve basically never done before? And of course, there’s prior art out there and all those things, but we have to map that then into our specific domain, our specific team and constraints.

    And so, a lot of that is figuring out—okay, we know that we need to do a thing and we have some basic sense of that, but how do we map that into our process? And you certainly described it as our model for building the software as opposed to just thinking about building a thing.

    Ashley: Well, we’ve run out of time. Rob, we should just grab a beer or a coffee and finish this conversation in about three hours.

    Zuber: I’d love to. Perfect.

    Ashley: [Laughter] Sounds great. Well, thank you for being a guest on the podcast. This is Rob Zuber, CTO of CircleCI. Appreciate you joining us.

    Zuber: Yeah, thanks so much for having me. It was great fun.

    Ashley: It’s been a pleasure. And also, thank you to you, our listeners, for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • Quality Engineering Has DevOps and Agile in the Driving Seat

    Quality Engineering Has DevOps and Agile in the Driving Seat

    As opposed to the traditional software development lifecycle (aka waterfall), today’s Agile and DevOps-based software development process is more outcome-oriented. The unrelenting pace of the changing market landscape has made the hybrid, Agile plus DevOps way of software development absolutely critical in addressing customer demands and staying competitive.

    The focus on Agile and DevOps is necessary due to the high failure rates of traditional software development methodologies. These failure rates are mainly attributed to the glitch-infested, low-quality applications churned out by following legacy methodologies.

    The failure rates had left many companies to bite the dust and brought the key role played by quality in ensuring customer satisfaction and ROI for the business into sharp focus. Also, the IT landscape is witnessing developments such as mergers and acquisitions, increased focus on risk and compliance, data and analytics, the fast rollout of apps and mobile commerce, among others. These have necessitated the software development process to become increasingly agile, streamlined, collaborative and flexible. The reshaping of customer expectations is letting organizations to go beyond shift-left testing or DevOps testing by transforming the QA process into one driven by quality engineering.

    What Is Quality Engineering?

    To meet the growing demand for quality software applications in double quick time, a mere tweaking of the software development process is not enough. What is needed is the adoption of software quality engineering process comprising optimal quality assurance, predictive analytics and monitoring of QA elements to reduce glitches to negligible levels. The process would involve a continuous cycle of feedback and quality improvement based on the same. The quality engineering process offers maximum test coverage in the shift-left scheme of things and ensures outcomes like functionality, security, accessibility, usability, performance and reliability of the software application. It complements Agile and DevOps methodologies and ensures their outcomes to remain consistent with the desired business objectives. Quality engineering, instead of identifying the inherent glitches in the SDLC, focuses more on preventing them altogether.

    Shift Left and Strengthen Right

    Quality engineering services cover the entire spectrum of the SDLC thereby yielding the maximum test coverage and delivering the best quality product. With DevOps testing shifting left, the quality determinants are incorporated right into the product build during the development phase. At the same time, DevOps-based QA focuses on the shift-right approach to ensure the last stage of the SDLC i.e., delivery goes on unhindered and customer feedback is taken in right way and worked upon. The ultimate aim of both shift-left and right is to create and deliver a glitch-free product that meets the requirements of the end-users. Here, since end-users are the ones who ultimately assess quality of a software product based on parameters such as usability, functionality and performance, among others, the feedback mechanism should be responsive enough to understand the issues faced by the end-users and remedy them at the earliest.

    Quality Engineering as an Aid

    Quality engineering (QE) helps to bridge the gap between development and deployment processes, which can arise due to the lack of agility. It harps on the successful strategy of “test early, test often,” to pre-empt challenges that businesses face when testing a software product. Quality engineering ensures the quality of a software application throughout the SDLC–right from the designing stage to its final delivery. QE can be incorporated into the development process by using methods such as Behavior-Driven Development (BDD), Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) respectively.

    Let’s find out what these methods are all about:

    • BDD: In this software development method, the behavior of both the software and business outcomes are taken into consideration. Here, the right sets of tests are automated, leading to an increased collaboration among developers, testers and other business stakeholders.
    • TDD: In this software development process, the QA team writes unit level tests before the development stage. This results in getting an early feedback and helps the development team to refactor its requisites.
    • ATDD: This software development process focuses on writing an acceptance test even before the development phase. This helps the software to meet the acceptance criteria beforehand.

    Quality Engineering and DevOps

    QE, being an end-to-end testing methodology, can offer optimum solutions to businesses struggling with their legacy IT infrastructure. The solutions in terms of continuous testing and integration as mandated by DevOps, can be arrived at by integrating the QA process with the DevOps pipeline. This results in executing processes such as build, test, deploy and deliver in a seamless manner. QE complements DevOps and Agile by detecting glitches right at the beginning of the development process.

    Moreover, QE’s focus on end-to-end testing helps the product to be developed and tested simultaneously. This approach adds teeth to the DevOps’s requirement for continuous integration (CI) and continuous delivery (CD). No wonder, the successful implementation of quality engineering is underpinned on fulfilling the requirements of DevOps and Agile. It further consolidates the benefits achieved from implementing DevOps testing services and Agile testing services.

    QE riding on DevOps and Agile can help businesses to scale up their operations without investing much resources and time. By implementing DevOps test automation and Agile test automation using a test automation software such as Selenium, Robitium etc., businesses can boost their SDLC. QE can help businesses to develop and deploy glitch-free software speedily and deliver enhanced customer experience.

    Conclusion

    The fast-changing competitive business landscape of today requires organizations to streamline their operations, increase productivity and fast forward the delivery of glitch-free software applications. To achieve these objectives, they need to make quality engineering as part of their development and testing cycles. However, QE ends up complementing the Agile and DevOps approach by achieving outcomes such as CI and CD. Furthermore, it leads businesses to get high ROI, better productivity, reduced cost of operations and enhanced customer experience.

    — Akshaya Choudhary

  • Autodesk Builds Better Software Faster with CloudBees Core

    Autodesk Builds Better Software Faster with CloudBees Core

    Autodesk Builds Better Software Faster with CloudBees Core

    Autodesk embraces DevOps, CI & CD to strengthen its competitive market position and deliver higher quality software and features to its customers even faster.

     I am convinced that we could not have done this without CloudBees. 
    George Swan
    Senior Director, Build Platform
    [su_youtube url=”https://www.youtube.com/watch?v=1gwHCV_njDg&feature=youtu.be”]
  • How to Implement an Effective CI/CD Pipeline

    How to Implement an Effective CI/CD Pipeline

    DevOps bridges the gap between development, operations and IT services teams efficiently. To foster a DevOps culture, implementing the right DevOps tools with the right DevOps process is essential. Continuous integration/continuous delivery/continuous deployment (CI/CD/CD) help developers and testers ship the software faster and safer in a structured environment.

    Unlike the traditional software life cycle, the CI/CD implementation process gives a weekly or daily update instead of monthly or quarterly. The fun part is customers won’t even realize the update is in their applications, as they happen on the fly.

    A Brief Insight About CI/CD/CD Terminology

    • Continuous Integration: CI is a process in which developers integrate new codes into a shared repository several times a day. This is a better approach than the traditional one, where the developer will build new codes in isolation and then integrate into the main repository at the end of the project lifecycle. The primary goal is to detect any integration bugs at the initial stage so it can be rectified quickly. It triggers a new build whenever a new code merges with the existing main repository. Test runs are performed against these new builds to check for any breakage.
    • Continuous Delivery: At the end of the CI, CD comes in. CD ensures to automate the software delivery process and commits to deliver the integrated code into the production stage without any bugs or delay. CD in the DevOps implementation process, helps developers merge the new code with the main branch consistently so they can build an instant software-ready product. It is responsible for checking the quality of the code and performs tests to check whether it can release the functional build to the production environment.
    • Continuous Deployment: The most critical part of the automation occurs at this stage of the delivery pipeline. Whenever there is an important change in the code, the corresponding build and deployment occur simultaneously. It is achieved through continuous deployment process where it allows to perform live deployment changes for every code modification that passes through the CI stage. During this stage, there is no manual intervention right from the initial code until the code is in the production stage.

    Benefits for Implementing CI/CD

    The ultimate aim for any software application is to reach its potential customers faster than ever before. This is exactly what the CI/CD pipeline offers to any business model that leverages a software process which reduces the risks in each build and helps the end product to reach the customer quicker.

    • Achieve Faster Feedback Through CI Tools: For every committed code, the corresponding tests are run simultaneously to avoid any link breakage at later stages. Faster feedback helps to check the quality and impact of the code.
    • Greater Visibility: With CI/CD pipeline setup, the whole process of new builds, test results and any issues with new builds can be analyzed. This transparency allows the developers to know which changes in the build led to the brokerage and to avoid them in the future.
    • Early Bug detects: Conducting various types of automated testing allows to identify any bug issues at an early stage without any last minute surprises. These automated tests along with few manual test runs, help to fix any issues that may arise.

    The Different Stages of CI/CD Pipeline Implementation

    To get the full benefits of the modern DevOps environment, embarking on a scalable CI/CD DevOps implementation is important. It lays a strong foundation for building an agile DevOps for your business.

    Tools for the CI/CD Process

    Tools are the magic wand that help automate a successful CI/CD pipeline and ensure a faster software delivery.

    • Open-Source Tools or Proprietary: Depending upon the budget and the client’s requirement, business can opt for open-source tools such as Jenkins for automating the CI/CD process.
    • Cloud or Self-Hosting Services: To self-host your CI/CD application, tools such as Jenkins and Cruise Control help to setup, configure and monitor the application effectively. Otherwise, you can get SaaS providers to host on cloud services.
    • Build Status: Choose a tool which embraces the transparency and visibility of the entire process through appropriate notifications, through email or other type of communication.

    Possible Challenges of CI

    • You might need a discipline strategy to address an issue by the CI/CD pipeline, otherwise the whole fast feedback is in vain. 
    • Slower builds eventually take place as newer builds keep adding to the product.
    • Failure to train the resources to adapt to new tools and patterns.

    Wrapping Up

    In this era of faster software shipping and building quick releases on the fly, adopting a more robust project cycle that accelerates the delivery pipeline is crucial. Implementing DevOps services is the optimal way to get the effective collaboration between cross-functional teams through the CI/CD process.

    — Jay Elango

  • Continuous Delivery Foundation Momentum Picks Up

    Continuous Delivery Foundation Momentum Picks Up

    The Continuous Delivery Foundation (CDF) this week revealed that it now includes 33 member organizations, including now JPM Chase, eBay, Dell Boomi, Cycloid, White Source, the Association of DevOps Professionals and the DevOps Institute.

    Founded by CapitalOne, CircleCI, Cloudbees, Google, Huawei, IBM, jFrog, Netflix and Salesforce in March the CDF is committed to promoting the adoption of open source continuous integration/continuous deployment (CI/CD) tools and platforms. Dan Lopez, CDF program manager, said the CDF plans to launch technical committees soon that address areas of CI/CD interest, including cybersecurity, software supply chains, software delivery management and machine learning algorithms in IT operations (MLOps).

    The CDF is not focused on promoting one open source CI/CD platform over another as much as it is fostering cross-engineering whenever feasible. As such, Lopez said the CDF is trying to advance adoption of the open source Jenkins and Jenkins X CI/CD platforms as well as the Spinnaker platform from Netflix. As other open source technologies are presented to the CDF, a technical oversight committee will evaluate them for inclusion, he said.

    At present, the membership of the CDF falls into three broad categories: companies that build tools and platforms, companies that leverage those technologies to deliver products and services and end user organizations such as JP Morgan Chase, eBay and CapitalOne.

    Lopez said the next goal is to expand the reach of the CDF beyond the U.S. and Europe to create a global CI/CD community. It’s not clear how many CI/CD platform providers will join the CDF. However, as membership in the CDF increases, pressure to join continues to mount.

    In the meantime, DevOps teams should expect collaboration between vendors to accelerate the pace of innovation across the entire DevOps life cycle. Vendors will be able to more easily identify areas to collaborate on that don’t provide much in the way of differentiation and yet are critical to advancing DevOps adoption.

    While a lot of progress has been made in terms of CI use, CD has proven to be an especially thorny challenge for most organizations. That’s become a significant challenge as organizations build applications at a faster rate and in many cases are still being deployed manually in production environments. Via the CDF, vendors are hoping to promote adoption of best practices across the entire DevOps toolchain as they gear up to introduce additional products and services that assume a strong CI/CD foundation is in place.

    It’s not clear to what degree the CDF will be able to accomplish that mission, given that most of the CI/CD issue organizations encounter are more cultural than technical. At the very least, however, organizations struggling with these issues should find solace among other like-minded souls wrestling with the same issues.

    — Mike Vizard

  • Automated Multiplatform Deployment for DevOps

    Automated Multiplatform Deployment for DevOps

    In a simpler world, every CI/CD pipeline would need to support only one deployment platform.

    In the real world, multiplatform deployment (which means deploying an application to run on multiple OS platforms) is a must-have for many organizations. We live in an age of diverse operating systems and deploying for only one platform is often not an option.

    With that challenge in mind, let’s take a look at best practices for achieving multiplatform deployment in DevOps.

    Dealing with Multiplatform

    Maybe you’re designing a container-based multiplatform app from scratch. Perhaps you’re thinking of converting a traditional, monolithic, client-server application to microservices with continuous delivery. Or, it may just be time to expand your existing DevOps delivery pipeline to include multiple platforms. The truth is that sooner or later, most DevOps teams will need to understand and deal with multiplatform deployment and how it impacts continuous delivery and continuous integration.

    What are the basic problems DevOps teams face in orchestrating automated deployment for multiple platforms? Let’s look at the key issues involved in multiplatform deployment, and the most effective ways to deal with those issues within the context of an automated DevOps continuous delivery chain.

    But first, we’ll consider one of the most basic distinctions in multiplatform architecture.

    Multiplatform, Single-Tier

    In the single-tier model, the same stand-alone application is deployed to multiple platforms. This is, of course, the standard model for releasing traditional desktop applications. The update process for many of those applications, however, has shifted toward frequent, automatic push updates to the point where it now constitutes a form of continuous delivery. This is typically the case for web browsers, for desktop office suites and for more specialized applications. It is also the rule for stand-alone mobile apps.

    Multiplatform, Multi-Tier

    In multi-tier and multiplatform deployments, different platforms have different roles, and the elements of the program deployed to a platform depend on its role. Typically, this involves some sort of client-server architecture, with the client part of the application installed on mobile and/or desktop devices, and the server functionality deployed in a cloud or hybrid cloud environment, or an on-premises server. At the enterprise level, on-premises hardware is likely to consist of one or more mainframes.

    We’ll focus mostly on multi-tier applications; much of what’s covered here should, however, also be relevant to single-tier multiplatform deployments.

    Designing for Multiplatform Deployments: Overall Architecture

    Fundamental decisions about application architecture will inevitably have a major impact on your deployment strategy. Key members of your DevOps team should ideally be active participants in decisions regarding overall architecture; at the very least, your team needs to be kept up to date on the design process.

    This is particularly true when the application has a hybrid backend, with key tasks split between cloud services and on-premises hardware, since the allocation of tasks is likely to shift as the design team develops a better understanding of both the resources required for those tasks and the load-handling ability of each platform.

    Example: Cloud Transactions, Mainframe Database

    Suppose, for example, that you have a very large and complex database that includes both customer and transaction records. It must be maintained on a mainframe because it includes legacy elements, or for security reasons, because of company policy, or (as is often the case) for all three reasons. Your application is likely to involve a high volume of transactions and other customer traffic, most of which will be stored in the database. In order to shift traffic away from the mainframe, customer interactions will be processed in the cloud, with transaction data initially stored in a cloud database, then transferred to the mainframe database.

    • Will the cloud database represent an actual field-for-field subset of the mainframe database, or will data need to be cleaned up and parsed before it’s transferred to the mainframe?
    • Will you be porting database code from the mainframe to the cloud, or creating a cloud-native database (i.e., COBOL vs. SQL)?
    • Will all user access be through the cloud interface, or will the app switch between the cloud and direct access to the mainframe, depending on the load?

    Questions like these are likely to have a major effect, not just on microservice and code-level design, but also on deployment strategies, since they will determine such things as how closely database microservices must be coupled on the two platforms.

    Designing for Multiplatform Deployments: Platform-Specific Issues

    In order to design a multiplatform application at the end-user and backend microservice levels, and deploy it using automated tools, it is crucial to have a clear and detailed understanding of the resources available on each platform, and of the dependencies they require.

    For the frontend, this may mean maintaining separate versions of your app for Android, iOS, Windows, OSX and Linux. For the cloud-based parts of your back end, you may be able to work in a relatively standardized container environment. Even here, however, you will need to be familiar with the resources and requirements of the specific cloud provider.

    On mainframes, you will need to have a good working knowledge of the mainframe environment, including the operating system and the available resources. This is a necessity for native mainframe operating systems such as z/OS, and it is still largely true if you intend to use a virtualized OS such as Linux on Z, since it is likely to have significant interaction with the underlying system resources.

    Designing for Multiplatform Deployments: Automating the Pipeline

    Keeping track of platform-related issues and managing their impact on your continuous delivery pipeline may seem like a formidable task, but it doesn’t have to be that difficult.

    The key is to develop an adequate understanding of the platforms involved, to incorporate that understanding into your automated tools and all of the target platforms into your automated delivery chain. This means (for example) automated testing across platforms, dependency checking for each platform, coordinated deployment and integrated monitoring.

    A variety of tools, both open source and proprietary, are available for all of these purposes and they can often be integrated into an automated continuous delivery system.

    Integrated Tools for Multiplatform Deployment

    There are, however, considerable advantages to using a highly integrated suite for fully orchestrated deployment. For example, if you are working with IBM Z, UrbanCode provides you with an integrated suite of DevOps tools that is fully integrated into the z/OS ecosystem. It is an agent-based system that includes tools for design of automation processes, multiplatform deployment, dependency checking, inventory and integrated monitoring; and it is specifically designed to manage multi-tier deployments.

    The advantage of working with a highly integrated deployment suite such as UrbanCode is that you do not need to spend time learning what to automate, learning how to automate it or putting together the basic automation infrastructure. You can concentrate on managing the specific automation components and settings your continuous delivery system needs. When you are dealing with a large, complex and business-critical platform such as a mainframe, an automated deployment suite that is highly integrated with that platform, can be an extraordinarily valuable (and time-saving) resource.

    Automated multiplatform deployment for DevOps may be challenging, but it’s eminently possible. The tools are there, and you can make it work.

    — Michael Churchman