devopsy.kinsta.cloud

Tag: open source

  • DevOps Chat: Chef Goes All-In on Open Source

    DevOps Chat: Chef Goes All-In on Open Source

    In front of next month’s ChefConf in Seattle, Chef has announced a major refinement to its business model. Affirming and clarifying its commitment to open source business models, Chef will now and in the future release all of its software as open source.

    In this DevOps Chat, we speak with Corey Scobie, SVP of Products and Engineering at Chef. He explains that Chef will be adding services, training and support to the open source software, as well as packaging all of this together.

    For the full story, be sure to listen to the podcast and check out the video version of this interview below, along with coverage on devopsy.kinsta.cloud.

    [videopress nUXwRMxU]

    Transcript

    Alan Shimel: Hey everyone, It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to a DevOps Video Chat. Today’s DevOps Video Chat features Corey Scobie, SVP of Engineering, is it?

    Corey Scobie: Product and engineering, yep.

    Shimel: Product and engineering now at Chef. Hey, Corey, welcome.

    Scobie: Thanks, Alan, happy to be here.

    Shimel: I’m happy to have you here. Today is a red letter, big day in the history of Chef. You guys are announcing some pretty significant changes to the model is I guess what I would call them. Though, I don’t think the changes are as big as some may initially feel, but let’s go over them. I’m going to let you take the wheel here. Tell our audience.

    Scobie: It is a big day today for us at Chef. We are announcing some changes to the way we both produce and ultimately distribute our software, which I think are really exciting. There’s a lot going on in the industry right now. As you probably know, Chef has been one of the marquee players in the open source software development community for some time. Part of the announcement that we’re making today that I think is most exciting, is we’re announcing that what we’re going to do is going forward, produce 100 percent of our product-oriented software in that open source model.

    For us, that’s a change because we, over time, and through the addition of additional projects and additional software at Chef, had started following a little bit of an open source, open core path, which means that we had some proprietary software and some open source software, but when we got down to it and we thought about the history of Chef and the roots of what has made Chef such great software in the past, it really came down to collaboration. We realized the best way to make software is to make it in collaboration with the people that actually use the software, at the end of the day.

    For us, that’s the big first talking point about the announcement is that we are committed to 100 percent open source software development going forward. We’re committing all of our software to open source repos and GitHub, and then ultimately attaching it and giving it to the commons with the Apache 2.0 license.

    Shimel: Sure, so Corey, you know – so you’re talking to someone who has a bit of a history in open source, 20 years. I remember when the whole open core movement first came out. Look, Richard Stallman and that crew, they were really against open core, because they felt it was – it was almost heresy to the whole cathedral and bizarre open source kind of crowd, where if it’s open, it’s open. You can’t be a little bit pregnant. But, nevertheless, we’ve seen companies succeed with this open core or premium, where the core is free and there are premium modules on top of it, but it’s a slippery slope. In all honesty, I think Chef got caught in a little bit with that slippery slope with what’s truly open, what’s free, what is our proprietary that we make money from? I don’t know if the market really got it.

    Scobie: Yeah, one of the things that is really tough when you’re following an open core strategy is drawing a very clean line between what is free and what is not free in the world of your technology offerings. For us, that got complicated and then even conflated further as we added more projects to the list. When we opened the InSpec project for security and compliance, when we opened Habitat for application automation, what ended up happening is we had multiple projects that were governed different ways that had different lines between the free and the core part of it. I think ultimately at the end of the day, had I been at Chef during that part of the journey, I probably would have made the same decisions, I’m guessing, but at some point you get back to this reconciliation point where it’s like, “Look. The best thing that you can do for customers if number one, you can collaborate with them, and number two, you can have a really, really clean line between what is free and what is not free in your world.”

    For us, it becomes super simple with this announcement. What is free is all of the intellectual property that we’ve contributed to the commons in the world, and will contribute to the commons going forward. What isn’t free is all of the work we do to make a turnkey, enterprise-class, package that enterprise-class customers can pick up and distribute at hyperscale in their organizations, from that point.

    Shimel: That brings us to the next thing, and of course this is always the issue. So if you’re going to make all the software and the IP open, well how the heck do you make money?

    Scobie: Sure. As it turns out, we’ve got venture capital funding, investors that want to see us turn that into dollars as well. For what it’s worth, we’re feeling pretty good about the shape of the business right now. We just came off the best quarter of revenue we’ve ever had at Chef, prior to this business model, this model change around how we distribute software whatsoever. So we’re feeling really good about the shape of the business, but just the inability to have that simple conversation about what’s free and what isn’t. What we decided was as we’ve matured as a company, and as the space has matured in enterprise automation, what we found is the majority of our customers actually do want to have a very material commercial relationship with us.

    Not only do they want the software, but they want the support. They want the content. They want the expertise. They want the warranties and indemnities that go with all of that. So for us, it was very simple. We realized at the end of the day, that the most — that there was a huge constituency of our customers who what they wanted from us was a very curated commercial offering out the other end. So we’ve decided that’s where we’re going to put our effort and our energy, and we’re going to trust in the open source world to fill in the gaps where that isn’t the offering that they want as well.

    Shimel: We look at this model, Corey. Obviously, Red Hat’s the poster child for much of the open source world in that most of their software, if not all of it, was in fact open source. It was all in the packaging and the support, and that kind of thing. It sounds very much like that’s going to be the model, or am I wrong?

    Scobie: It is – no – there’s a strong analog to what Red Hat has done in the industry as well. What’s interesting is I think that that is the antithesis of what we are seeing from a lot of the more recent moves in the open source industry where there’s a desire to become more proprietary in some cases, or in other cases to try and somehow bend, I think, the definition of what is open source software. For us, the core of it, we get back to the four freedoms, and freedom zero is about the freedom to use the software, but it’s free as in freedom. It’s not free as in dollars.

    Shimel: Free as in freedom, or free as in beer, as we used to say, but Corey, to be fair to these companies that are – that we do see going another way, it’s because they didn’t cut it. They tried the Red Hat model, and for whatever reason, they didn’t cut it and they had too much pressure from their boards and the VCs and investors, and so forth. So they tried to take a path that was quicker to money. I’m not here to judge anybody’s – as someone in the Godfather once said, “Far be it from me to disparage what someone does for a living” –

    Scobie: I hold the same opinion, Alan, by the way. I sit in judgment of nobody on the decisions that they make about what’s right for their business. I just know that for us, what’s right is to try and both honor the open source roots that we came from, and to also serve the commercial customers that were really knocking at the door and saying, “Look, this is what we want from you. We want even more engagement. We want even more value out of your commercial subscription.”

    Shimel: Agreed. Before we jump into the next part of it, which is how it manifests itself within the Chef universe, I wanted to just tie a knot on this one, and mention that when we talk about this model, and you said, “Oh, we’re going to count on the open source community to fill in the gaps,” and one might say, “Well, what are those gaps? I think people have to realize what made Red Hat great was not just distributing Linux. It was that RHEL, and Fedora even before that. It was that package, that distro, that had everything you needed and wanted in there in a really easy to use – you didn’t want for anything else. It was all right there, nicely done for you, instead of running out and having to download different packages and distros from all over the internet, which is what held back Linux on the desktop for so many years. There wasn’t that one package that you could do that.

    I think that’s what you’re referring to is Chef’s strategy going forward is to have that killer distro, with all the right packages in it. If you don’t want to pay Chef for that, and I don’t think at this point, though people like software that is free as in beer, and they get free as in freedom with it, no one denies that a company should be able to make a living, that a company should be able to make a profit, pay its employers, pay its developers, and go forward. So for people who either don’t have the money, or don’t have the inclination to buy the packaged product, they can get the open source components, and the community can work on giving you the glue, in essence, that puts these all together. Correct?

    Scobie: Absolutely, for sure. Santos came out of that exact scenarios. The scientific community needed something that wasn’t going to be necessarily nearly as curated as Red Hat and Linux was, but they needed a platform for scientific computing, so CentOS was born and has a place in that world. I think our vision for that is exactly the same. If there’s a downstream project that is born of Chef InSpec or Habitat, we welcome it into the community, and we look forward to whatever innovations they bring, and we want to collaborate with anybody that wants to come and take that work out of the commons and create the derivative work out of it, that allows them to meet whatever their goals are. That is the freedom in free and open source software.

    Shimel: Absolutely. I think one of the other things though, Corey, is when we look at Chef over the last couple years, we’ve seen the whole InSpec line of security functionality, and we’ve seen Habitat. Look, Habitat was an ambitious piece of – well, it was more than a piece of software. Habitat was an ambitious play, but because there was so many balls in the air and going off in different directions and open/closed, proprietary/not, people never – it wasn’t explained well enough to people. I spent the time at ChefConf so I understood Habitat well, but there’s maybe a thousand people at a Chef conference as opposed to millions of people in the world. I think it was really hard getting InSpec and Habitat, carving out their niche in the world, amidst this whole confusion around the closed/open, supported/paid for, free/not free.

    Scobie: Yeah, that’s fair, and I think this really helps us simplify the messaging around that too. I will openly admit I think InSpec is an easier basic value proposition to parse, which is “Look, I need security and compliance in my organization and the right way to do that is express it as code”, so that should be fairly straightforward, and relatively noncontroversial. I think, with respect, to Habitat, what is interesting about Habitat is I agree with you, super ambitious project right from the get-go to redefine the abstraction of packaging and orchestrating the delivery of software in the world.

    That’s – it’s huge that there’s a huge surface area associated with that. I think what’s interesting is that we’ve learned much – we’ve learned a lot over the last couple of years about how to help people in the mental journey of how to think about Habitat in the world, and how it relates to Chef, and having that foundation of understanding and knowing Chef, which tens of thousands, if not hundreds of thousands of people already have, the ability for them to jump to where Habitat plays becomes much easier in the world where we can talk about them collaterally and not independently of one another.

    Shimel: Fair enough. I think that’s a great segue, Corey, to the next part of our conversation I wanted to have with you, and that is okay, how does this manifest itself down the line of Chef product and services? So we’re going to put all our IP out as open. I guess we should mention also, I think everything is being released under an Apache 2.0 license.

    Scobie: That’s correct. Apache 2.0.

    Shimel: Industry standard, GPL, Apache are probably the two biggest. How does this manifest itself? What changes does this mean for Chef’s products?

    Scobie: On flag day when we release new products with new packaging and new terms and conditions, it’s an evolution that we’ve been going through for some time now, which is really to understand what the interface parts are between the three core engines that we have. So we’ve created an engine for infrastructure automation, which is the Chef project, and going forward, just from a purely – from a branding simplicity perspective, it’s going to be known as Chef Infra, which is I think is fairly straightforward.

    Shimel: I’m sorry. Can you repeat that though? Chef…?

    Scobie: Infra, as in infrastructure.

    Shimel: I-N-F-R-A. Okay.

    Scobie: Yeah, and then we’re going to have Chef InSpec, for security and compliance, and the state relationship between infrastructure and security and compliance are pretty – it’s pretty intuitive, which is that if I deploy an operating system, and I want it to be locked down in a certain way and secure and meet a certain set of compliance standards, then testing that on a continuous basis, managing the drift, and being able to automatically remediate any drift that’s happening there seems like a really obvious relationship. What’s interesting though is the relationship between infrastructure and application automation. This is where things get really murky, even for longtime Chef customers who have been wildly successful in using Chef as an infrastructure automation tool. If you go and talk to those customers, what you’ll find is that they’re doing about – 30 percent of what they’re doing is about infrastructure deployment provisioning and shaping, locking down configuration management.

    70 percent of what they’re doing is deploying software on top of the operating systems in service of some application that’s going to come along at some point in time and need that – those software dependencies to be there. What we discovered, and this is really the genesis of Habitat, which I’m not even sure – we knew that what was happening in the space of Chef was not working at scale for us. That’s the reason that some folks at Chef went off and decided to create Habitat, but what we didn’t realize is why it wasn’t working as it was at the time. The reason is that there is a natural boundary for building systems from the bottom up in a layer cake approach. It doesn’t matter whether it’s Chef or Antival or Puppet or Kubernetes clusters or whatever, that there is a natural boundary layer, if what you’re doing is building systems from the bottom up.

    So you have an operating system, and then you have system libraries, and then you have packages, and then you have middleware, and eventually you have an application. At some point that dependencies graph, the modularity of everything that you lay down, and the dependencies graph gets so complicated that there’s no possibly way you can manage understanding what the implication of changing component X is on all the other components that rely on X. So the beauty of Habitat and where Infrastructure, and where Chef and Habitat come together is that Habitat takes the exact approach. It says, “Look, what you should do is you should define an application, all of the application’s dependencies and all of the orchestration steps for that application to run successfully in any environment regardless of where it is.”

    So by doing that, and by removing that layers – that bottoms up layers dependency, what we’ve really done is created an application stack, an enterprise automation stack is what we’re calling it where infrastructure and application automation marry together at a very, very clean abstraction level. The abstraction level is essentially, if you’re running software on the operating system that runs above the kernel, it should be defined by application packages and orchestration, and not by infrastructure packages and orchestration. Now, it’s architecturally it all makes sense, and it actually works really well in practice. Where it’s complicated is that organizationally, INO – traditional INO operators and other infrastructure groups have been tasked with more and more software deployment on top of their stacks. So this is a very paradigm-shifting idea. I think what is helpful for us is the enterprise automation stack allows us to create a framework and a template for how to do that in a way that helps customers adopt that methodology much, much quicker.

    Shimel: Fair, fair. So we got Chef Infra. We have Chef InSpec.

    Scobie: Yes, and Chef Habitat, Chef Habitat.

    Shimel: Chef Habitat sits – I wouldn’t say it sits on top of them.

    Scobie: Look, the stack is – we have trouble with this with our marketecture diagrams. If, what happens in the podcast now is you’ll throw up the marketecture diagram you’ll have, what you’ll see is a linear stack, but the state relationship between those three things is much more complex than can be defined in a diagram like that.

    Shimel: _____ diagram, sure.

    Scobie: Then on top of that, then there’s two other pieces to the portfolio. So we have Chef Automate, which is the observability layer on the top. Of course, if you have automation on all of these things, you want to be able to see across all of your pipelines, across all of your applications, across all of your systems. What is the state of everything that’s running? How has it been deployed? Is it in compliance or not in compliance, etcetera? So we’ve got this whole enterprise dashboard with automation up top. Then on the bottom end of the stack is we need to make it easier for developers to get started. So all of these engines are representative of either infrastructure compliance or application automation as code. What do you do as a developer? You download a bunch of tools. You get started writing code that are the artifacts that actually drive that automation. So Chef Workstation is the compilation of all of those tools and an easy way to set up your development environment to get going. That’s the entirety of the enterprise automation stack. It’s Chef Workstation, Chef Infrastructure – Chef Infra, Chef InSpec, Chef Habitat, and Chef Automate on top.

    Shimel: And repeat for me, what all of these packaged together is the –

    Scobie: Yeah, the Chef Enterprise Automation Stack.

    Shimel: That’s the whole enchilada, so to speak. This is all packaged up into one coherent type of product, if we can call it that. Fair?

    Scobie: Exactly. Yeah, one coherent distribution, absolutely.

    Shimel: Corey, you know the news broke today around this. Some are saying, “Well, Chef is pivoting. Chef is this.” How do you view this? How do you and the other folks at Chef view this? Is this really a pivot? To me, it’s – I don’t see it as a pivot.

    Scobie: Yeah, it’s not a pivot. I mean, first of all, I don’t think it’s – we’ve – you can question the effectiveness or the efficacy of our open source strategy in the past as we’ve meandered through different phases of that, but this is us staying true to the fact that we are an open source company, and so I think we’re leaning into the business model by which Chef was founded, and by which we’ve been operating for quite a while.

    Shimel: I agree with you.

    Scobie: I think from a technology perspective, we just have more clarity now in how to deliver the components and technology that have become critical to customers who are trying to solve large-scale enterprise automation problems. I don’t know that I would really describe it as a pivot. I think what we’re trying to do is use this as an opportunity to reintroduce people to Chef who maybe haven’t heard of the latest of our innovation in InSpec and Habitat, as an example, who maybe are not familiar with the work that we’ve been doing in the last three or four years. For us, it’s a little bit of a rebirth, but I wouldn’t call it a pivot.

    Shimel: I don’t know if I’d call it a rebirth. So here, look, you’re in the forest.

    Scobie: I am in the forest. There’s no question.

    Shimel: [laughter] I’m outside the forest. To me, obviously a pretty – I’m more than a casual observer. To me, Chef was always an open source company.

    Scobie: Always.

    Shimel: I think in some ways, what we’ve seen with Chef over the last five years, I would characterize as growing pains for an open source company trying to come to grips with remaining true to its open source roots, while at the same time recognizing you took other people’s money, and that’s how – I lived that life for 20 years. You take other people’s money, they want – it’s a funny thing. They want to get a return on their investment. It’s like trying to serve two masters. It’s a hard – it’s a hard –

    Scobie: Not only that, but look, the successful commercialization of any open source project or software company is how you actually create sustainable good in that community for the long-term. Obviously, you need participation from the community, but you also have to inject capital into that community if you want sustained innovation.

    Shimel: You have to extract revenue as well though. That’s where I think it gets dicey. So when I look at InSpec and Habitat, I almost feel at some level, they were somewhat hobbled by having to live in this schizophrenic, open/not open, making money/not making money. Well, if it’s totally open, we’re not making money. How much do we put into this? There was just too much of this all over the place, where to me, this is just a clarification. Look, Chef is and will remain an open source company, and our value to our investors is that No. 1, we have this tremendous community around us who are users of our software as well as contributors to the community, but No. 2, we are now offering a proprietary, a for-profit solution that takes the best of this and packages it up nicely.

    Scobie: Absolutely. Look, Alan, you make a great point. I would love to give a shout out to the community, because the Chef community is absolutely amazing. I know you’ve been to ChefConf. It’s an experience in and of itself. It’s hard to think of another tech conference that is as authentic and as welcoming and as diverse as ChefConf is, and it’s a bunch of people that come together every year, because they are passionate about solving the challenges of infrastructure management at scale, and application deployment at scale, and all of those things that Chef is interested in as well. So the community is a really key factor of it, but to your point is that there’s just this growing demand in the enterprise. We are the experts in figuring out how to do that in a really, really tight curated way. Of course, we’re going to take advantage of that market opportunity as well.

    Shimel: Sure, we got the news out. Is there any part of the news we’re missing, Corey?

    Scobie: No, I don’t think so. That really covers the announcements for today. I think the only other thing is we’ve got ChefConf 2019 coming up in Seattle May 20th – 23rd in Seattle. It’s going to be a great event. We also have a ChefConf for the first time ever, ChefConf coming to London at the end of June. It’s June 19th and 20th, I believe are the dates in London.

    Shimel: Really?

    Scobie: Yeah.

    Shimel: You know I’ll be in London those dates. I’ll have to talk to you about it.

    Scobie: Yeah, absolutely. We’d love to see you there, and we’d love to see others there as well. Yeah, so we’ve got a couple big events coming up where we’re going to showcase the latest of the innovation that we’ve had on all of the fronts, innovation, compliance, application automation, our enterprise consoles, all of that kind of stuff. so those are going to be fantastic events coming up. So other than that, we’re looking – we’re really looking forward to getting back to those community roots and really everybody being there together in the trenches together building the next generation of what this is all going to be.

    Shimel: Cool. So now let me ask you a question. Put on your wizard’s hat. If we’re talking about ChefConf 2020 now, a year from now, this strategy, this road has been – this strategy has been implemented now. We’re going down this road. How does it manifest itself over the next 12 – 24 months you think?

    Scobie: Look, we’ve been talking about that from a product strategy perspective, and I think we’ve got – there’s a lot of opportunity for us to do great work in pulling the pieces of the puzzle together, even more explicitly. We’re doing a lot of work with partners, so I anticipate that the ecosystem partners will be a big player in ChefConf 2020 as well. So we’ve been working with the likes of everybody from Microsoft, Azure DevOps, and the workflows there. We’ve got – we’ve been doing some product work, and continue to do product work with Amazon in the ops work for Chef Automate, managed and hosted to platform there. We’re quite engaged with GitHub because we’re seeing both GitHub and Artifactory and a lot of our customers in the DevOps toolchain and pipeline there. We’re doing some work with that. We’ve been doing a lot of integration with services now. So I actually think that the next phase of this is not just about the Chef parts of the stack, but how those parts of the stack connect with the rest of the ecosystem that is fast emerging in the enterprise automation space as well.

    Shimel: Sounds cool. Well, Corey, we’re about out of time. I want to thank you for taking time on what’s a crazy busy day for you guys, to brief our audience on this. Congratulations to the whole Chef team. Tell Barry and everyone else, looking forward to ChefConf. Unfortunately, I won’t be at ChefConf in Seattle. I’m in Europe, but we’re going to have a full team there doing video interviews there and everything. John Willis, our partner at Digital Anarchist will be there, and Chris Reilly. So we’ll have plenty of Chef coverage from ChefConf. Like I said, I didn’t even realize the London one. We’ll try to get over there. I think that’s Tech Week in London actually, which is a pretty big week.

    Scobie: Yeah, fantastic. Well, thank you so much, Alan. I appreciate you taking the time today as well. Look forward to seeing your colleagues at ChefConf in Seattle, and then hopefully we’ll see you in London in June.

    Shimel: Absolutely. Hey, Corey Scobie, SVP Engineering and Product. I got it right.

    Scobie: You got it right.

    Shimel: You’re talking to us about some news coming out of Chef today, a little bit of a change in how they package stuff, but they’re still an open source company. Corey, thanks very much.

    Scobie: Thank you, Alan.

    Shimel: Take care. This is Alan Shimel for devopsy.kinsta.cloud, everyone. Have a great day.

    — Alan Shimel

  • Chef Commits to 100 Percent Open Source Code

    Chef Commits to 100 Percent Open Source Code

    Chef has decided to open source its entire portfolio of IT automation software as part of an effort to make it easier for organizations to construct a DevOps pipeline using the company’s software.

    A part of that effort, Chef also launched the Chef Enterprise Automation Stack—which combines Chef Infra for managing infrastructure, Chef InSpec for maintaining compliance, Chef Habitat for managing applications, Chef Automate for managing hybrid clouds and Chef Workstation, a starter kit for launching Chef—within a single distribution of Chef software. Chef Infra is the original Chef project around which the company was launched.

    Corey Scobie, senior vice president of product and engineering for Chef, said the company previously offered a mix of open source and proprietary software that made engaging with some customers overly complex from a licensing perspective. This approach aligns the entire Chef business model around providing support for open source software, he said.

    At the same time, Chef is now open to collaborating more closely with developers who want to contribute code to its various projects. That’s critical because code contributions are now the primary means through which many IT organizations help shape the direction of products as they continue to evolve, Scobie noted.

    Of course, many IT organizations today either mandate the use of open source software or have instituted an “open source first” policy that makes it challenging for any proprietary software to be adopted.

    Chef expects that by making its software easier to consume via a unified open source transition it will be able to further accelerate adoption of what is described as a “Coded Enterprise” to managing IT. Rather than manually configuring IT assets in isolation, that approach encourages organizations to adopt best DevOps practices that treat all aspects of IT, including infrastructure, as code, said Scobie, adding that capability is more important than ever as IT organizations are increasingly require to manage heterogenous cloud computing environments.

    Chef claims that approach has already resulted in more than half of the Fortune 500 having adopted at least one module of its software and, in the fourth quarter of 2018, the highest level of bookings in the company’s history.

    While Chef helped pioneer the IT automation category, competition across this sector has intensified. Chef and its primary rivals Puppet and Red Hat are the leading proponents of frameworks for automating IT operations. Although adoption of those frameworks has increased substantially in recent years, use within IT organizations often remains fragmented, often resulting in islands of automation. Chef is clearly hoping that IT organizations will increase adoption of its software stack now that it’s  based entirely on open source software. Many organizations face challenges teaching their IT operations teams enough programming skills to automate their processes. In absence of those skills, adoption of IT automation frameworks within the context of a set of well-defined DevOps best practices often remains uneven, at best.

    — Mike Vizard

  • Comparing Nuclio and AWS Lambda

    Comparing Nuclio and AWS Lambda

    With serverless, you delegate the responsibility of running your infrastructure to a platform provider as much as possible. This frees your engineers to focus on building what your customers want from you—the features that differentiate your business from your competitors’. For this philosophy to work, however, the platform needs to not only give you the tools to build those features, but also deliver the performance that will keep engineers satisfied.

    Yes, services such as AWS Lambda are powerful, but they have a number of well-documented limitations that make them unsuitable for some workloads. These include:

    • Cold starts and high latency make them unsuitable for real-time applications that require consistent and millisecond-level response times.
    • The pay-per-invocation model makes them costly in high throughput scenarios.
    • The event-driven model, coupled with a max execution time or data size restrictions, makes them unsuitable for long-running tasks or heavy data or AI processing.
    • They are limited to triggers and event sources that are specific to the cloud provider.

    Enter Nuclio, an open source serverless platform that is built on top of Kubernetes and comes in both managed platform-as-a-service (PaaS) and self-hosted flavors. In this post, we will compare Nuclio with AWS Lambda, see how Nuclio addresses the above limitations and explore the new use cases Nuclio is unlocking, such as:

    • High throughput data processing pipelines or ETL.
    • Serving machine learning models in real time.
    • Real-time applications such as multiplayer games.
    • Long-running jobs and services.

    Nuclio vs. AWS Lambda

    Concurrency

    One of the biggest shifts from traditional application development to AWS Lambda is how concurrency is managed. An Express.js web application running in a container/VM can handle multiple requests concurrently. In other words, your application manages its own concurrency. You scale the application by increasing the number of concurrent requests it can handle (scaling up) and then increasing the number of containers (scaling out).

    Figure 1: Traditional applications scale up the currency within the application, then scale out the number of nodes running the application.

    With AWS Lambda, concurrency is managed by the platform, and a concurrent execution would process only one request at a time—much like an actor in the actor model, which would process one message at a time. The application can scale out by increasing the number of concurrent executions of the function.

    Lambda’s concurrency model has its advantages:

    • It simplifies application development. Concurrency is a constant source of bugs and performance issues, as developers struggle with writing highly concurrent applications.
    • It allows you to price each invocation individually because you don’t have resource contention from handling concurrent requests. This enables the pay-per-use pricing model and is one of the cornerstones of findev.

    Still, Lambda also has some disadvantages:

    • You can’t make use of idle CPU cycles when a function is waiting on IO. Since most functions are IO-heavy, this results in significant inefficiencies.
    • It requires more scaling, which means more cold starts. To handle X concurrent requests, you need X concurrent executions, which equates to X cold starts. This makes it nearly impossible to achieve predictable performance.

    Nuclio, on the other hand, can scale up as well as out. A function processor (analogous to a container) can host multiple function workers. Each worker is then able to process one message at a time. This system supports concurrency within the same processor, and then autoscales the number of replicas of the processor based on load.

    Figure 2: The architecture of a Nuclio function.

    Another interesting difference between Lambda and Nuclio is that Nuclio lets you specify both the minimum and maximum number of replicas. And as an aside, Nuclio also supports GPUs.

    Figure 3: Nuclio lets you configure both the minimum and maximum number of replicas.

    With Lambda, you can configure a reserved concurrency for a function, which (counterintuitively) sets its max concurrent executions. But there is no way to tell the system to always keep a certain number of concurrent executions running at all times. The system always scales to zero when there is no traffic—behavior that is highly undesirable for systems that experience regular spikes in traffic.

    For example, my employer, DAZN, is in the sports streaming business. We see huge spikes in traffic all the time, as millions of users flood in seconds before a sporting event starts.

    Figure 4: Sports streaming platforms, such as DAZN, experience huge spikes in traffic just before a sporting event kicks off.

    Without the ability to configure the minimum number of concurrent executions, these spikes result in large numbers of cold starts. Also, in these cases, Lambda has to scale out the number of concurrent executions quickly to meet the surge in demand. Here, we also run into the 500/minute limit on how quickly Lambda is able to scale out. As such, we are currently not able to use Lambda on the critical path of our system, which has to shoulder these spikes.

    With Nuclio, you can programmatically update the minimum replica count prior to the event so that when the spikes come, you don’t have to worry about hitting scaling limits or enduring the performance hit from cold starts. You can also tell Nuclio to scale to zero immediately via API calls, which saves resources.

    Figure 5: Adjusting the minimum number of replicas enables you to deal with predictable spikes in traffic.

    Timeout

    Another major difference between Lambda and Nuclio is how timeout is handled. With Lambda, an invocation can run for up to 15 minutes. While it’s possible for you to use recursive functions or step functions to extend this limit, both approaches have their own problems. As such, Lambda functions are great for event-driven architectures and performing short, ephemeral tasks.

    With Nuclio, there is no max execution time. The containers can keep on running, which in turn allows you to go beyond the constraints of the event-driven model. You can now turn a function into a long-running service, which unlocks some interesting use cases such as long-running ETL jobs and training machine learning (ML) models.

    Caching State Between Invocations

    Both Lambda and Nuclio functions accept an event and context during an invocation.

    Figure 6: Both Nuclio and Lambda functions accept an invocation event and context as arguments.

    With Lambda, the context object is ephemeral and does not persist between invocations. If you want to persist data between invocations (e.g. static configurations, database connections), then you need to declare them as global variables outside of the function handler.

    With Nuclio, the execution context itself is persisted between invocations and can be used to cache state. The context object also includes a built-in logger, which supports structured logging with JSON and four log levels: DEBUG, INFO, WARN and ERROR.

    You can configure the default log level for a function and can even override this default log level per invocation—which is very useful for debugging. You also have the ability to export your logs to external services such as Elasticsearch.

    Figure 7: With Nuclio, you can select the default log level for every function.
    Figure 8: You can also override the default log level for an invocation.

    In addition, there are hooks for performing context initialization, which is called before the first invocation on the function. This allows you to perform initialization logic before the container is put into active use and removes the dreaded cold start problem that Lambda suffers from.

    Data Volumes and Persistent Data Connections

    With Lambda, functions only run when they are triggered by events. Furthermore, concurrent executions are garbage-collected when they have been idle for a few minutes. This behavior makes life difficult when you are working with relational database management systems (RDBMS) and other systems that require persistent connections. Indeed, a set of guidelines has been developed to help you avoid the many pitfalls of using Lambda with RDBMS. Furthermore, Lambda doesn’t allow you to use persistent data in standard file system mounts, which forces you to copy to/from object storage before working on large files such as images, logs, ML models, etc.

    With Nuclio, however, you can use the context object to maintain persistent connections to databases. Since the context is maintained at the processor level, you get better reuse, as they are shared across invocations. You can also take care of other aspects of data-fetching with data bindings, including batching and caching, which helps improve IO performance of the application. Additionally, you can mount volumes to functions, which is useful for working with ML models or Tensorflow, and you can mount Kubernetes secrets as volumes. Indeed, Nuclio supports all of the volume types that Kubernetes supports.

    Runtimes

    Both Lambda and Nuclio support popular languages such as Go, Node.js, Python, .Net Core, Java and Ruby. Also, both platforms offer a way for you to customize the execution runtime.

    With Lambda, you can create a custom runtime and distribute it through AWS Lambda Layers. This lets you introduce additional language runtimes that are not natively supported by the Lambda platform. Several vendors have published runtimes for PHP, Rust, Erlang and Elixir, to name a few.

    With Nuclio, you can run functions on your own Docker image (see Figure 9), which can come from a private image repository. This allows you to tailor the execution environment itself.

    You can also support additional language runtimes through a Shell function, which allows you to handle invocation events with any executable binary. See this example for more details.

    Figure 9: Nuclio lets you run functions on top of your own Docker image, which can come from a private image repository.

    Triggers

    Lambda is supported by a wide range of event sources.

    Nuclio ships with 13 triggers, including cron, HTTP, Kafka, Kinesis and RabbitMQ. Since Nuclio is open source, you can also write your own trigger for services that you want to integrate with and leverage other people’s contributions. The HTTP trigger gives you an easy way to integrate Nuclio with other event sources that support HTTP as target, such as SNS. Also, since Nuclio supports the CNCF CloudEvents standard, it can arguably support many more event sources that are CloudEvents-compliant.

    Nuclio triggers are all normalized to the same Event object. This removes the need to understand the specific event signature for each event source, which is often confusing when working with Lambda. It also makes it easy to switch a function between different triggers.

    Built-In HTTP Trigger

    With Lambda, you need to use API Gateway to create an HTTP endpoint for your functions. API Gateway is a feature-rich service, but it’s also complicated and often costs more to run than the Lambda invocations themselves. It also adds another source of latency to your API, which, at the minimum, is around 5ms to 10ms, and it can overhead spike to more than 100ms. This cost and latency overhead make it unsuitable for applications with high throughput or hard real-time requirements.

    With Nuclio, every function gets a private HTTP interface by default. To expose the endpoint publicly, you need to specify an HTTP trigger similar to API Gateway. However, unlike API Gateway, this HTTP trigger does not incur extra costs and has minimal latency overhead.

    Figure 10: With Nuclio, every function gets a private HTTP interface by default.

    Unlocking New Use Cases with Nuclio

    As you can see from our comparison, Nuclio differs from Lambda in a number of important areas, such as its concurrency model and that it has no max execution time. This opens the door to a whole range of use cases. Let’s take a moment to look at a few.

    High-Throughput Data Processing Pipelines or APIs

    For a high-throughput API, the cost of both API Gateway and Lambda is drastically higher than an equivalent application running in containers. This cost discrepancy has lead many to rewrite their applications.

    Nuclio’s concurrency model makes more efficient use of available resources, which significantly reduces operational cost when running at scale. Functions have built-in HTTP interfaces so you also don’t need to pay for an expensive API Gateway service.

    The ability to mount a volume to your function also lets you read and write data to/from a mounted volume at high speed and enables building stateful applications. Again, you can’t do this with Lambda today, as it doesn’t allow you to attach Amazon Elastic File System (Amazon EFS) volumes to functions.

    These features make it economically feasible to run high-throughput and high-performance APIs on Nuclio functions. The same can also be said about high-throughput data processing pipelines that have to process multiple terabytes of data per hour.

    APIs with Predictable Spikes in Traffic

    Nuclio gives you the ability to configure a minimum number of replicas. This allows systems that experience predictable spikes in traffic to reserve sufficient resources ahead of time and avoid degrading the user experience when the spikes happen. Examples include food ordering services such as Just Eat or Deliveroo or sports streaming services such as DAZN.

    At the same time, Nuclio still lets you scale to zero by setting the minimum number of replicas to zero. It gives you the control to optimize for resource usage or latency, depending on the situation.

    Real-Time Applications

    Nuclio does not suffer from cold starts and is able to deliver consistent and sub-millisecond response times on invocations. This makes it a suitable solution for applications with a hard, real-time requirement such as multiplayer games and real-time bots.

    Serving Machine Learning Models in Real Time

    To serve ML models in real time, you need to have both strong and predictable API latency and the ability to load and work with ML models that often are large in size (GBs).

    Nuclio lets you attach Kubernetes volumes to your functions, and there are no size limits on these volumes. Combined with the performance characteristics, it’s possible to implement these demanding workloads with Nuclio functions.

    Nuclio also has native integration with Jupyter, and lets you automatically deploy Jupyter notebooks and ML models as Nuclio functions.

    Long-Running Jobs and Services

    Nuclio does not impose a max execution timeout on function invocations. This allows you to turn your functions into long-running services and perform long-running ETL jobs.

    Nuclio’s init_context() hook lets you create long-running services, such as an application that constantly reads off a Twitter feed (e.g. loads the TwythonStreamer with the context, which is polling an external service, versus becoming triggered by an event).

    Conclusion

    As we discussed, Nuclio is one of the few open source solutions that are also business-viable. It has key architectural advantages for higher performance or data-driven applications, including:

    • Nuclio is cloud-agnostic. It can be used in multi-cloud/hybrid-cloud scenarios. You can also run Nuclio on a laptop using plain Docker, which makes debugging easier.
    • Nuclio’s concurrency model and the ability to mount file volumes lets you build high-performance APIs and high-throughput data processing pipelines.
    • Nuclio gives you greater control over the concurrency of your application, which makes it viable even for applications with very spiky traffic.
    • Nuclio’s execution contexts are persisted between invocations, and it doesn’t impose a max execution time on invocations. This allows you to create long-running stateful applications such as ETL jobs.
    • Nuclio lets you attach Kubernetes volumes to your functions and has no limitations on the size of the volume. This makes it possible for you to work with large ML models that often are GBs in size. Nuclio also has native integration with Jupyter and can automatically deploy your Jupyter notebooks and models as functions.
    • Nuclio provides a good out-of-the-box developer experience. It has a built-in logger with structured logging support, and you can easily export your logs to an external log aggregation service.

    If you are looking for a serverless platform that is not tied to a specific cloud provider, Nuclio is worth a look.

    — Yan Cui

  • 7 Ways to Introduce DevOps in Your Work Culture

    7 Ways to Introduce DevOps in Your Work Culture

    As many industries are going through a wave of digital transformation, a number of key technologies and principles are being deployed to business advantage. One such principle is DevOps.

    This collaborative principle is proving to be extremely helpful for businesses in their pursuit of customer satisfaction and beating their competition.

    The DevOps trend is growing, as cloud providers including AWS, Azure and Google Cloud are moving faster in upgrading their DevOps services and tools to address business needs.

    According to a Google Cloud and Harvard Business Review Analytic Services report, “two-third of companies that use DevOps have seen benefits impacting their bottom line, including productivity (67 percent), increased speed to market (70 percent), innovation (66 percent), customer relevance (67 percent) and product/service quality (64 percent).”

    While most companies are already reaping the benefits of DevOps practices, some organizations are still doing their homework. Here are seven tips to help you understand how your organization can use DevOps to its advantage:

    Begin with a Small Project

    It’s always best to start with a small project before you start engaging DevOps practices on a large scale. A pilot project will enable you to understand the core capabilities of the DevOps process and how you can map them to your business objectives.

    Utilizing Open Source Tools

    Using open source tools will keep you in touch with current trends and practices. Open source tools are easily available and easy to integrate. You can use these to enhance your DevOps experimentation.

    Introducing Security

    The DevOps process faces a threat in terms of security, which can be disruptive to an organization’s reputation. Hence, it is advisable for organizations to introduce security at the early stages of the DevOps process. Additionally, it saves a lot of time and resources, which are very crucial aspects of the DevOps process. The concept of DevSecOps is a wiser approach as it includes security all through the software development lifecycle (SDLC) process.

    Make the Most of DevOps Best Practices

    Looking for a process that drastically improves productivity and reduces time to market? DevOps best practices are designed to increase the pace of software development. With practices spanning site reliability engineering (SRE), end-to-end automation, continuous integration, testing and delivery, proactive monitoring and more, your team will be able to utilize their time effectively and devote their attention to other important business-driving processes.

    Enhance Team Skills

    The key to bringing out effective production results is having a skilled team that is equipped with the necessary training. Therefore, it is essential for organizations to provide their employees with a proper understanding of the organization goals in general and the processes employees are part of. According to the report, three-quarters of the best DevOps teams said they provide hands-on learning experiences with code labs and projects exercises.

    Avoid the Blame Game

    DevOps aims to bring about an increased pace of operations and fast learning, among employees. But most of the time for any new process to fall in place, individuals involved have to experience failure. And with the failure of the first project often comes the blame game. However, organizations need to understand that failure is the initial step to achieving future success. Moreover, firms should adopt the policy of “fail and adjust sooner.” The experience of learning from mistakes will take you farther along in your DevOps journey.

    A DevOps-Friendly Environment

    A DevOps-supportive culture is incomplete without the above exercises. Hence, it is essential that organizations bring about an environment that provides room for shared goals, improved transparency and making growth-driven decisions.

    So, industry change-makers: Are you ready for your DevOps experience?

    — Veritis

  • DevOps Chat: The CD Foundation, with CloudBees’ Kohsuke Kawaguchi and Tracy Miranda

    DevOps Chat: The CD Foundation, with CloudBees’ Kohsuke Kawaguchi and Tracy Miranda

    A new foundation, the CD Foundation, has been formed under the auspices of the Linux Foundation to serve as the home base for a vendor-neutral movement committed to making it easier to build and reuse DevOps pipelines across multiple continuous integration/continuous delivery (CI/CD) platforms.

    The first projects to be hosted under the auspices of CD Foundation includes Jenkins, the open source CI/CD system, and Jenkins X, an open source CI/CD solution on Kubernetes. Both were developed by CloudBees. Netflix and Google, meanwhile, are contributing Spinnaker, an open source multi-cloud CD solution. Google is also adding Tekton, an open source project and specification for creating CI/CD components.

    Founding members of the CD Foundation include Alauda, Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    In this DevOps Chat we speak with Kohsuke Kawaguchi (aka KK), founder of Jenkins and CTO of Cloudbees, and Tracy Miranda, open source community director for CloudBees. They give us the insight behind the CD Foundation and what the future may be for Jenkins, JenkinsX and CloudBees.

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

    Transcript

    Alan Shimel: Hello everyone. It’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is about some big news that came out in the DevOps continuous integration/continuous deployment world, CI/CD. That is the founding of the CD Foundation and it’s part of the Linux Foundation. It was announced just this afternoon. I’m happy to be joined by a couple of folks from one of the founding members—really one of the pivotal founding members of the CD Foundation, CloudBees. From CloudBees, joining us, joining us today is Tracy Miranda, who is director of open source community at CloudBees, and none other than KK himself, founder of the Jenkins Project and community as well as founder and CTO of Cloudbees. Kohsuke, Tracy, welcome to DevOps Chat.

    Kohsuke Kawaguchi: Thanks for having us again.

    Shimel: Kohsuke, it’s always a pleasure to have you. Tracy, I know you’re new to this, but thank you for joining with us.

    Tracy Miranda: Yeah, [inaudible].

    Shimel: Guys, big news today. Linux Foundation starts the CD Foundation. CloudBees is one of the founding companies, and if I’m not mistaken, a board member of CD Foundation as well. Is that correct?

    Kawaguchi: Yeah, exactly. We are part of what – I think 20.

    Miranda: Yeah, I think we’re up to 23 members now.

    Shimel: I think it might have been 25.

    Miranda: Wow [chuckle] I think it’s continuously growing.

    Shimel: It’s funny. I spoke to a few companies today after the announcement. They mentioned that they’d like to join in it. That’s for them. I’d like to understand and maybe, KK, this is a question for you. What was the motivation to turn Jenkins and Jenkins X – we’re talking about two significant projects – over to this new foundation and to the Linux Foundation?

    Kawaguchi: From the Jenkins – I have multiple hats to wear in this, but from the Jenkins project perspective, a key part of it is we wanted to create this level playing field that creates – that accelerates the innovation in Jenkins family. The Jenkins family as you know, it’s been benefiting pretty much everyone in every organization, and there are a lot of companies with an eye on Jenkins. We want to drive them more into the project. We move the project forward together. In that way, I think we can do it faster. In case of Jenkins X, it’s been critically designed on a number of projects that’s coming out of the CNCF, which is a sister foundation that is also under the Linux Foundation. It made a lot of sense we’d be bringing these projects closer so that we can again collaborate faster. So those are, I think, very convincing obvious benefits for two projects.

    Now the CTO of CloudBees, CloudBees has been the biggest contributor of behind the Jenkins project. This move made a lot of sense for us as well, because one, our customers rely on a lot of open source projects and ecosystem. When those foundational resource projects that’s driving is strong, then obviously that benefits CloudBees and our customers. I think that’s a fairly obvious move for us as well. Also importantly, we – well, I, talk to a lot of people in the – our customer and prospect organizations and those technical people understand the need and the benefits that the objectivity really brings. I often see them struggling while the rest of the organization around them. Here, I talk about things like money, people, and time to invest in these efforts. It make the necessary business impact.

    I feel like a part of the role that I’m really looking forward for the CDF to play is to advocate the practice of continuously, elevate it beyond the technology practice. Again, like the CNCF for cloud-native, thereby we can make a bigger impact in the world. That’s the kind of thing a single vendor cannot very easily do because people automatically assume the intention behind these things, or a pitch behind them. Open Source foundation, there’s multiple vendors, and also the end user companies like _____ and _____ adds a lot of credibility and authenticity to that message. For all of these reasons, I think it’s kind of a no brainer, a win win win across the board. That’s how I think about it.

    Shimel: I think that’s a great way of looking at it. Tracy, let me ask you, you’re the liaison to the open source community. In this case, we’re really talking about the Jenkins community and Jenkins X. How is this announcement – it’s kind of new still, but what’s been the feedback from the community on this?

    Miranda: Yes, it’s been really, really positive. We’ve been talking to the Jenkins community, well, the Jenkins board members, Tyler and Kohsuke, the kickoff conversations over a year ago. Since I’ve come in as well, we’ve been keen to get everybody involved with how this would shape up. We’re hearing lots of exciting things. Some things we hadn’t even predicted at the beginning. So for example, Jenkins has a very emerging and very strong and enthusiastic Chinese community. They are super excited about using CDF as a way to really expand in China. I think we can look to that for new areas we want to expand into. So yeah, on the whole, very positive. Lots of enthusiasm which is fantastic.

    Shimel: Absolutely. As a matter of fact, I’m somewhat familiar with the Jenkins community in China. One of our partners held the Beijing Jenkins Day while I was out there last year. So I had a chance to meet a lot of those folks firsthand. It was a very enthusiastic group. They’re doing great things there in DevOps and CD as well. I’m sure it’s been used as well as Jenkins X. Actually, one of the founders of the Jenkins X project was presenting there that day. He was in from Australia. It was very, very well received. Back to this, both for Tracy and KK, one of the things I think people really admired about CloudBees was it wasn’t the usual vendor open source project manager relationship.

    So many of these open source projects that are managed by a single vendor tend to be run for the sole benefit of that vendor whether it be OpenCore or Razor-Razorblades kind of thing. Decisions are made for the benefit of the commercial vendor, oftentimes at the expense of the community. CloudBees was always above that. All these years there was an independent board. There was independent steering and governance of the Open Source community and project. With that already in place, KK, does that negate some of the reasons why you would need a separate foundation, or that just accelerates it?

    Kawaguchi: Yeah, so thanks for the nice words. We’re already proud of the way we participate in Jenkins project. I think there are two factors to that. One is number of people who founded CloudBees. They all come from open source background, the _____ folks, RedHat folks. We share a lot of – it’s like a common body. And that really played a critical part in recognizing, understanding how open source community works. The other important part to call out is Jenkins project is not owned by CloudBees. It is an independent project with its own decision-making process. This project, mind you, it came out of the drama with – well, a certain company. I won’t name names.

    Miranda: [laughter]

    Kawaguchi: So I think the people in the community felt really strongly about their independence. So we discussed it. So, in moving to CDF, many – well people are outside CloudBees, they also continue their _____ CloudBees. They’re also very anonymous desire and preference to come over to CDF because they see it as the next step of the governance to ensure this level playing field, which I touched on a little earlier. Then I think that’s been – that was seen as very valuable characteristic. I think the CloudBees has done good things over the past year _____ the project. I think it’s time to also codify and turn it into something more stable and fundamental. I think that’s what this move to CDF signifies.

    Shimel: I think that’s true. I think there’s another element too, KK. When we look at the history of Jenkins, when something is so successful, you don’t see many contenders. That was true with Jenkins. When Jenkins burst on the scene – we don’t have to go into the history of it, but Jenkins burst on the scene, and it quickly became the dominant CI and then CD tool of choice, not only for the DevOps community, but for the software developing and ops communities. Everyone used Jenkins. Recently, in the last year or two, three years, we’ve seen other contenders coming up, many of them commercial.

    Some of them have an open source, open core, kind of program business plan, but nevertheless, people had this, “Well, Jenkins is older, or it’s yesterday. This is tomorrow.” I think by putting it in a foundation like this, it guarantees a tomorrow. It’s the old, “So many eyes on the code, it has to be better” story. With so many hands in the pot, it has – it’ll accelerate faster. So that’s a good thing. I feel like we’re neglectful though. We should mention beyond Jenkins and Jenkins X, there was some other great software programs that were contributed to the CD foundation today, correct?

    Miranda: Yes, that’s right. Would you like to hear a little bit more about those?

    Shimel: Yeah, please.

    Miranda: We’re super excited. One of the other projects is Spinnaker, is what Netflix originally put together for continuous delivery. That is a well-known, a well-loved project in this space. We were really excited they bought into the vision and wanted to be part of it. Then the other project, last year Google announced the Knative serverless platform. As part of that project, there’s a build and pipeline side of it which has been renamed to Tekton. Tekton is the pipeline and build part of – behind Knative. What’s really exciting about this project is that we’re looking as part of the vision of CDF to really focus on integration and sharing concepts and making tools work together. Tekton will be the pipeline engine, set the definitions for which Jenkins X are going to evolve to. Spinnaker are going to look at it too, and for Jenkins’ next generation pipeline, there’s lots of exciting things in the work. Just really excited about all the possibilities coming up.

    Shimel: Sure. We should mention both Spinnaker and Tekton were contributed by Google.

    Miranda: Google and Netflix for –

    Shimel: And Netflix yes, for Spinnaker. But that’s not all. Once a technical oversight committee is formerly introduced, there may be other projects that are – come under the CDF management as well, correct?

    Miranda: Yes. Absolutely. I think one of the things we outlined in the charter is we want to focus on the entire software delivery life cycle. We want to have a whole set of complimentary projects. So we’re  looking – there’s some really exciting projects in the world of mobile and other areas as well. It’s not just cloud. So lots and lots of exciting projects out there. We look forward to welcoming and onboarding those as we develop, and as we get up and running properly.

    Shimel: We should also – I just wanted to mention that some of the other companies involved as founding members of this CDF are Alibaba, Autodesk, Capital One, CircleCI, CloudBees, obviously, DeployHub, GET Lab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP. These are household names out there. This really is a heavyweight list of contributors, and I think guys, that that really talks to just how important CI/CD has become in the modern software factory.

    Kawaguchi: Like I said, it’s kind of on the cusp from growing from just the technology things to more bigger business impact. It took CloudBees all along, and so I’m really excited that this mission, this sense of passion is all shared by so many more companies. I think it makes the message a whole lot more critical.

    Shimel: Here’s another flip side. As this frees up CloudBees to really focus in on the commercial side of things. Though you weren’t – CloudBees didn’t manage Jenkins. The community and the Jenkins community managed itself. CloudBees played a – obviously it was a big role helping – making sure – KK, you’re wearing two hats with that. Now that CloudBees is freed from that, what do you think we’ll start seeing from CloudBees going forward?

    Kawaguchi: Actually, we are doing more than ever in open source. A number of key folks behind Nginx is at CloudBees _____. So just to make sure that this isn’t all a move by _____, trying to wash our hands away from it. In fact, it’s the opposite. At the last time also, CloudBees is getting bigger. We are working on a number of the products and services. So I don’t really see those things as mutually exclusive. I think everyone at CloudBees understands that those are both important parts of our business.

    Miranda: Yeah, and if I add to that, well, this one specific example, the DevOptics project, which focuses a lot on analytics, and these key measures you’re doing your software delivery. That’s one area where CloudBees is going to do a lot more and you’re going to see a lot more, and it’s pretty exciting going up to that next level.

    Shimel: Excellent. I would imagine you would. Tracy, if you don’t mind, this is going to be a change for you and how you deal with the open source community, or you think not really, not too much?

    Miranda: No, absolutely. I think it’s going to be quite different. We’ve got lots of different people working together. I think that’s what makes it really exciting, just having the different perspectives, the different ideas. I always say like with open source, what I’m most excited about is the unexpected things that you don’t really know what they are until they happen, the innovation, or the two people getting together and saying, “Hey, let’s take things in this direction.” It’s so full of possibilities that it’s really exciting.

    Shimel: I think it will be, and I think it’s going to be for sure. You know what, I haven’t read – who particularly from CloudBees is going to hold the board seat in the CD foundation? Has that been announced or decided?

    Miranda: So I’ll be representing CloudBees at Board of Directors, but also Kohsuke is heading up the technical oversight committee, which means he will also be at the board level. We’ve modelled a lot of the charter and foundation rules off the CNCF where it made sense.

    Shimel: Fantastic. That is really good. What about some of the other folks who are on the board of the Jenkins community board? People like Tyler and some of the other folks? Will they be – what will be their involvement going forward, if you know?

    Kawaguchi:  I think the charter will define the structure. It’s just got launched and we will, I think, in the coming days we will have people’s names and so on. I just don’t want to give the wrong information, but Tyler, for example, he’s been pretty instrumental in making this happen. So I expect him to stay involved in this going forward in some shape or form.

    Shimel: Absolutely. I realize it’s only announced today. You don’t have all the answers, but I thought I’d ask. So final question because we’re running low on time here is one of the – you called the CNCF a sister foundation, it would be hard to argue that hasn’t been a really successful effort by the Linus Foundation, and not just Kubernetes. Kubernetes seems to be the star pupil, or star favored child. There’s a lot of projects within CNCF that are really, really doing well. CNCFCon along with KubeCon is – to me, it was the most exciting event I’d been to certainly within the last six months, certainly since Jenkins World. Will there be a similar type of event now for CD Foundation? Or maybe you pitch one grand tent with CNCF for one big conference? Any ideas on that?

    Miranda: Well, first thing we have in place is that we are going to hold our very first continuous delivery summit. We’re going to co-locate that with the new KubeCon which is in Barcelona.

    Shimel: In May.

    Miranda: That’s right. Yeah, getting going quick. That will be our first opportunity to bring a lot of contributors together, a lot of the end user community as well. We just love the projects in CNCF. We want to continue collaborating closely with those folks. I think this will be a great first event. We did just hear today that there’s something like 12,000 people expected at that event in Barcelona. Big, big fans of CDCF.

    Shimel: Yes. I will be there – we’ll be there doing videos. Hopefully, we’ll get to, Tracy, meet in person, maybe do some video interviews there in person.

    Miranda: Yeah, that would be awesome.

    Shimel: Yeah, that would be great. Then, we’ll – I forgot when the next one. Well, after that, the Shanghai in July, and then in the fall is KubeCon back in North America. Will this be an ongoing collaboration or is that – after that, you might do your own?

    Kawaguchi: We don’t know that yet, I think.

    Shimel: Still to be decided. All right, well guys, congratulations first of all, on all of the new today. This sounds just so god darned exciting. It’s good stuff. Kohsuke, what can I say, man? You just keep doing it. Congratulations. Keep it up. Tracy, congratulations. I guess we’ll be hearing a lot more about the CD Foundation in the months and year ahead.

    Miranda: Yes, absolutely. Thanks so much, Alan. This has been wonderful.

    Shimel: You know what? I sound like Colombo. One last question. You’re probably too young to remember that, but anyway, why not CI/CD Foundation? Is CI becoming passé, out of style, we don’t refer to it? Or we’re just so focused on CD? Any thoughts on that?

    Kawaguchi: The practice that surround the continuous integration is still very much there. I just think of it as frontier moving on, and so therefore the concept is encompassing more and more. When we say continuous _____, so the _____ includes all of the things we talked about as CI. It just expanded into something bigger is how I think about it.

    Shimel: Yeah, all right, fair enough. Guys, again, thanks so much, Tracy, KK. Kohsuke from CloudBees on the announcement of the Linux Foundation setting up the CD Foundation and Jenkins, Jenkins X part of it. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to a minute of DevOps Chat.

    — Alan Shimel

  • How CI/CD Can Fast-Track Next-Gen Media Rollouts

    How CI/CD Can Fast-Track Next-Gen Media Rollouts

    Using CI/CD can help digital service providers move as quickly as over-the-top content providers

    Online video consumption has been increasing tremendously with rapid change in consumer expectations to have seamless viewing experience across various digital devices. To capture this growing demand, it is critical for digital service providers (DSPs) to deliver fast-track rollout of next-gen media services. Moreover, to counter the growing influence of over-the-top content providers (OTTs), DSPs must deliver media services that are high quality, right the first time and consistent, along with creating competitive advantage through speed to market. However, unlike OTT players, DSPs are challenged by extremely long development and rollout timelines for new services and offerings, primarily because of vendor-specific hardware and software applications that do not support rapid changes.

    Figure 1: Rapidly changing landscape of consumer video consumption.

    Embracing an effective continuous integration and deployment (CI/CD) setup can enable DSPs to achieve the same service innovations and delivery agility that OTT providers are offering. An important characteristic of an effective CI/CD setup is to create a fully automated deployment that is easy to operate and visualize. The setup also should have remote accessibility to ease parallel deployment at multiple geographic locations and a robust monitoring toolchain to monitor each step in the deployment process.

    However, implementing a CI/CD setup with these characteristics for next-gen media landscape comes with its own challenges; it requires end-to-end CI/CD orchestration, which is operationally complex. This involves stitching together different types of video services such as live TV streaming, VoD, electronic program guide (EPG), 4K/HDR, user personalization and profiling. These services need to be rolled out in multi-geographic locations and multi-tenant environments, catering to multiple vendors. The service must offer a seamless viewing experience across all digital platforms including TV, mobile, tablet and desktop.

    In setting up such complex processes, cross-functional and cross-geographic teams own different parts of the process, which can create gaps in design, infrastructure setup, configurations and eventually deployment. The CI/CD pipeline created can be costly and ineffective.

    Setting Up Effective CI/CD

    One-click automated delivery pipeline tool for predictable rollouts/rollbacks

    Create a one-click automated delivery pipeline tool that can facilitate automated change requests (CRQ) to initiate CI/CD jobs. The tool triggers the entire deployment of all the app components in the respective tenants across multiple geographies.

    Key considerations in setting up a one-click automated delivery pipeline:

    • Track CRQ approvals over systems such as JIRA to trigger the automated delivery pipeline.
    • Build pipeline as a code with intermediate CI/CD stages using open source tools such as Jenkins.
    • Design a master job to accept component and configuration details. This performs multi-job configuration and triggers contextual deployment/rollback simultaneously across tenants.
    • Interconnect different aspects of networks, infrastructure, components and applications to run the entire process smoothly.

    Setting up an automated delivery pipeline provides greater accuracy and predictability by reducing the human error factor.

    Automated snapshots, pre- and post-validation scripts to ensure consistency

    Create a fully automated snapshot management process that includes automated snapshot creation, rollback and deletion across respective tenants. Automated snapshots before deploying the new version of application facilitates rollback to the previous consistent version with zero downtime, if any failure occurs.

    Ensure automated multiple validation checks at every deployment stage to ensure consistency. These checks include validation of network connectivity, memory usage, CPU utilization, running applications, error and debug log files, license files, binary file size and configuration files. These validations can be done via tools such as groovy, ansible, Jenkins, python or shell scripts with proper libraries that match industry standards.

    Auto-scaling tool to optimize resource usage

    Ensure the application always has the right amount of capacity to handle traffic demands. This requires integrating an auto-scaling tool with predictive machine learning (ML) models and change request process to dynamically scale up/down the infrastructure.

    Key considerations in setting up auto-scaling tool:

    • Identify external and internal influencing factors to analyze system throughput.
    • Leverage insights derived from a monitoring dashboard to manage changes in current payloads.
    • Leverage triggers from a ML model to plan future expected system throughput.
    • Create automated configurable scripts to support dynamic scaling based on the inputs received from change request and ML model.

    Creating such tool enables better infrastructure availability with efficient cost management.

    Tool-agnostic and on-demand environment creation framework built on open source

    Leveraging open source tools provide flexibility and control over the entire exchange-to-exchange deployment process. Using customized framework with a layered approach makes the delivery pipeline tool-agnostic. It gives flexibility to easily replace/plug in any tools in the DevOps chain without much dependency.

    This ensures increased reusability, as the same toolchain can be used for multiple environment setups. Further, a customized framework dynamically handles the resources and utilizes the infrastructure effectively.

    Service assurance dashboard for stability and monitoring end-to-end processes

    A service assurance dashboard can provide glimpse of end-to-end CI/CD performance in a single window. It provides real-time graphical insight into failures/blockages in the pipeline, highlighted in the context of the overall flow. The dashboard should dynamically fetch data from the deployment pipeline for respective components and monitor how the upgrade/rollouts are processing. It should provide insight into resource usage, which can trigger dynamic auto-scaling and give a visual comparison of previous firmware with the new one.

    Implementing such a service assurance dashboard can provide greater visibility and help in easy diagnosis and error prevention.

    Benefits

    • Accelerated time to market with nearly 60 percent reduction in waiting time with parallel deployment across multiple tenants.
    • Improved predictability with significantly reduced fallouts and downtime/failure rates.
    • Optimized cost with approximately 50 percent lower IT spends in the deployment process and resource usage.

    This article was co-authored by Sumit Thakur, manager, strategic insights at Prodapt; Vijay Ramachandran, senior project manager at Prodapt.

    — Lakshmiprasad A

  • In AI Initiatives and Hybrid Clouds We Trust

    In AI Initiatives and Hybrid Clouds We Trust

    The 2019 State of the Union Address, delivered Feb. 5, was light on anything tech-related. But just a week later, Feb. 11, technology was the focus of an executive order that launched The American Artificial Intelligence (AI) Initiative. Why do we need a national AI initiative, and what does it have to do with DevOps? (Hint: You may need hardware and a hybrid cloud strategy for your AI initiative.)

    Investments in AI technology are exploding worldwide. Most analysts believe that while the total number of startups and equity deals to date still favors the United States, China is spawning startups rapidly, thanks to their recent AI initiative. According to just-released data from CB Insights:

    “While China accounted for only 10% of global AI deals in 2017, Chinese AI startups took 48% of all AI funding dollars that year, surpassing the US in AI funding for the first time.”

    The long tail doesn’t lie. A big global competition here is a good thing, though, and the scoreboard has spurred movement. The American AI Initiative lays out five principles, paraphrased in brief:

    1. We need to drive technological breakthroughs in AI.
    2. We need technical standards for development and testing.
    3. We need workforce training in skills and applications.
    4. We need to be able to trust AI solutions for privacy.
    5. We need both open markets and protection for “critical” technologies.

    Go, Team America! What, you expected more than motherhood and apple pie out of the White House? I’m not going there. I don’t think any administration could prepare the level of technical insight needed for something of this magnitude. It can, however, lay a course and task agencies for technology plans and funding proposals—and about two-thirds of this executive order is devoted to timelines for those.

    Let’s assume this AI initiative comes together with real dollars, and everyone including your competition is at work on AI. You may be thinking, “This is easy. I’m looking at a prominent cloud vendor’s machine learning webpage right now and it says, ‘No machine learning skills required.’ Its solution is based on its libraries of algorithms plus cloud-based workload acceleration hardware.”

    If that approach solves your specific problem, that’s great. Many use cases will fit those offerings. However, I’m thinking that a lot of you out there won’t turn over your data and your privacy control to a single vendor. Based on what I’ve seen, while the public cloud may be fast enough for some use cases, it’s woefully non-deterministic for others. You may be able to afford all kinds of time and elastic cloud resources for training, where time may be measured in weeks or months on bigger machine learning data sets.

    Real-time inference is a different game. There. Will. Be. Slowness. One missed result can be very costly—ask any autonomous vehicle developer, then look at all the hardware sitting in the trunk. Public cloud solutions are woefully non-deterministic, especially as everyone and their dog starts using them. The CEO of another big cloud vendor just said in an event keynote that most AI solutions will split 40/60 private/public cloud. She went on to say if you’re regulated, it’ll be more like 60/40.

    Most current startup investment is headed for AI chips. Machine learning is the ultimate workload optimization problem. By adding compute nodes with clusters of GPUs, FPGAs or dedicated system-on-chip (SoC) designs, inference speed-up is achievable. Whatever approach you chose, you’re probably going to want workload optimization safely in your private cloud instance within a hybrid cloud AI solution.

    You’re also going to want control over differentiation of your solution. Open source AI software solutions are great because they handle a fundamental base of value. However, AI-enabled applications are very likely to run into problems at scale. Open source will get you to prototyping quickly. Your innovation will be tested as real-world, real-time issues develop. If you can get a truly differentiated hybrid cloud AI solution that proves to be fast, reliable and secure, you’ll have a huge competitive advantage.

    Again, this looks like a perfect job for a DevOps team. Here’s where to start on your AI initiative, in increasing order of difficulty:

    • Have someone get familiar with machine learning and AI public cloud solution offerings—those vendors are easily found.
    • Also get familiar with open source frameworks such as TensorFlow, Caffe, Cognitive Toolkit, PyTorch, MXnet, DeepLearning4J and others.
    • Look at your preferred distributed computing framework for recent innovations in AI workload optimization; for instance, a lot of work is happening around Hadoop and Spark.
    • Inventory the problems you think AI might solve in your organization and see how they line up with those potential solutions.
    • Experiment and discover where the bottleneck in your preferred algorithms might be; those will be candidates for a hybrid cloud workflow optimized solution.
    • If there’s a profound bottleneck, you’ll need to evaluate the best hardware solution, meaning someone on your team (or a consultant) should understand GPU code or FPGA design.
    • For the most severe AI challenges, more companies will be considering either off-the-shelf AI chips or custom SoC designs—even companies that have never designed chips.

    My point here wasn’t to provide a primer on AI technology; that’s a huge topic. The American AI Initiative is a call that teams need to move on AI now or risk being left behind in the competitive prop wash. You also shouldn’t wait for someone to generate the exact solution you need out in the marketplace. With the feds driving a sea change in AI, investments and technology will be shifting even more rapidly, and it’s best to get in front of it.

    For the curious, here’s the entire executive order on the American AI Initiative.

    If you’ve started already, how’s your AI initiative going? Are there other areas in AI or machine learning you’re curious about that would be a good topic for future posts? Reach out if you’d like to discuss this.

    — Don Dingee

  • Why 2019 Will Be the Year for Shift-Left Mainframe Testing

    Why 2019 Will Be the Year for Shift-Left Mainframe Testing

    While 2018 was the year for planning and implementing shift-left methodologies in testing, mainframe and server testers were, for the most part, left behind. These legacy infrastructure experts were tied down to old-school testing tools. Mainframes kept functioning, but tools and testing practices often became bottlenecks, preventing performance testing teams from testing more quickly mid-cycle and pre-release.

    Until now.

    The future of testing is in open source, and finally there are open source solutions being developed and tailored for mainframe testers. Now, mainframe testers can also shift left and become agile.

    Here are four reasons why mainframe developers and testers will benefit from shifting lift and embracing open source testing technologies:

    Frequent Releases

    Apache JMeter, BlazeMeter (open-source based), Taurus and Jenkins are ideal substitutes for legacy tools, for two reasons. These open source tools are very easy to use, so developers and testers can use them themselves. In addition, they can be automated easily—once scripts are set up, they just run, and developers can get the results and monitor the system and their code.

    These two reasons are the building blocks of what shifting left is all about: frequent releases. There is a much quicker option than developing, waiting for QA to run tests, arguing with QA about the results, fixing the code, waiting for test results again, realizing you forgot to commit an important part of the fix, sending the code again, waiting for tests and pulling an all-nighter to fix the code for the last time only to realize that your code clashes with a team member’s code and you can’t release.

    By integrating your code tests into the development pipeline, every piece of code is immediately and automatically tested, on its own and encapsulated with other parts of the code. Once the code is approved, a new version is immediately released, to the customer’s/user’s benefit. This also benefits the developers by giving them a clean slate to continue working on. If the code needs fixing, no problem—an alert is sent to the developer, who can easily identify the problem and fix it. The fixed code is immediately tested and released. Now that’s much easier and much more motivating for everyone involved.

    Fewer Bugs, Higher Code Quality

    Shifting left means more automated tests are run—and more frequently. By constantly checking the system for errors and by running tests every build, you and your team are constantly being alerted of errors, which you can then immediately fix. The result is higher quality code and much better system performance.

    Another positive outcome is less hassle for your team when developing, because you don’t have to keep dwelling on previous version errors. Those have already been fixed or dealt with, so you can focus on future plans and exciting developments, which will materialize in higher code quality.

    Cost Reduction

    Shifting left means faster and automated testing, resulting in a higher-quality product. By running more tests in parallel all the time, testers and developers can focus on developing new code, resulting in savings for the business. If you’re running tests in the cloud, you’re also saving infrastructure costs.

    A higher velocity of releases with quicker fixes and new features results in more satisfied customers, who stay with you instead of moving to your competitors. Customers stay with companies they feel is concentrating on the future, which is why Gartner’s Magic Quadrant “Visionary” recognition is considered to be a big deal for the testing industry.

    Better Team Collaboration

    The idea of automation and continuous testing might come across as being detrimental to teamwork, but the opposite is true. Even though developers become more self-sufficient with their own code, this complete ownership actually encourages teamwork. Team members will collaborate more on joint feature development through shared workspaces and dashboards, with each developer bringing the code they produced to integrate with others. They also will work together to discover the system’s shortcomings and learn how they can fix bugs and bottlenecks.

    Shift-left and automation for mainframe means more time for feature development, getting customer feedback and responding to it; quicker fixes; and faster releases. This is crucial for competing in the market, providing the best services, attracting the highest-quality workforce and maintaining product security.

    Start Your Mainframe Testing with Open Source Tools

    BlazeMeter recently contributed the JMeter RTE plugin to the open source community. This plugin enables load and functional testing on JMeter for IBM 3270- and 5250-based applications.

    Running mainframe tests enables mainframe developers and testers to finally introduce agility to their testing habits, bringing mainframe testers in line with their coworkers who already embraced shift left and open source testing toolkits.

    — Refael Botbol Weiss

  • Edge Computing: Saving the Cloud from Ephemeral Data

    Edge Computing: Saving the Cloud from Ephemeral Data

    Edge computing is rapidly gaining momentum. Last week’s Linux Foundation news on the launch of LF Edge is one more sign of accelerating growth at the edge. What’s driving this sudden intense interest? It’s more than just the sheer number of edge devices or mounting concerns around interoperability and security. Pushing compute resources closer to the edge can save the cloud and networks from waves of ephemeral data.

    The concept of edge computing certainly isn’t new. In years BC (“before connectivity”), there were plenty of edge computing boxes. These featured single-board computers designed to specifications such as VMEbus, STDbus, PC/104, CompactPCI, AdvancedTCA and many others. Processing happened at the edge as data arrived. Ethernet connections made administration and results-sharing easier, but very few architectures relied on shipping all the data into the network.

    Of course, there was one big exception: a business model pulling all the data into the network. Telecom providers aggregated traffic from the edge into their core networks. As data traffic joined voice traffic, core networks grew with monstrous bandwidth and increased services. Core networks interconnected. Data traffic rose even faster, pushing the network into a cloud architecture. In years AD (“after distribution”), everything from the edge is now connecting to the cloud.

    Much of the increase in data traffic came from the shift to video content. Users expect higher resolution video programming with the same lag-free performance. Streaming networks and quality of service (QoS) implementations have made great strides in content delivery. 5G infrastructure rollouts in progress will keep mobile a strong downstream contender.

    What about upstream applications such as the IoT? Nearly the same terminology applies there. Devices gather data on the edge and transmit it to the cloud through a gateway. There are two key differences with most IoT applications, however. Real-time data may be lost if the streaming connection into the cloud is interrupted. Also, the fallacy of low bandwidth does not work at scale if all the data is transmitted. At some point—perhaps ten thousand, a hundred thousand, or a million or more sensors—an aggregate bandwidth problem develops.

    Just as in the BC age, it’s time to rethink shipping all that IoT data upstream, instead taking steps at the edge. Cisco Systems has studied data trends extensively, producing its white paper, “Cisco Global Cloud Index: Forecast and Methodology, 2016-2021.” The company points to the IoT ushering in the “yottabyte era” very soon. Cisco estimates that 220ZB of data was generated in 2016 and projects that by 2021, there will be nearly 850ZB from people, machines and things combined.

    Now for the interesting part: Cisco also estimates that as much as 90 percent of that data is ephemeral, short-lived data not useful to save. Even if only 10 percent of data is useful, it will swamp projected data center traffic by an estimated factor of four in 2021. Here’s Figure 24 from the Cisco white paper:

    Edge computing, or its close cousin fog computing, allows two things to happen: It can pre-process ingested data, ironing out protocols and format differences such that everything arriving at the cloud is immediately ready for algorithms. Any savings in the cloud from not shuffling data before computation are valuable, increasing processing and network bandwidth availability. Parts of an algorithm could easily be farmed out toward the edge, perhaps decimating or filtering data before shipping it upstream for heavy analysis.

    A bigger use for edge computing may be using algorithms to avoid shipping ephemeral data upstream altogether. Using generative models at the edge could make a huge difference in identifying useful data. Most of us have heard that no human can sit and watch hours and hours of surveillance video from multiple sources looking for one moment of a problem developing. Consider another example with an EKG monitor attached to a smartphone: While the patient is at home, at rest and unstressed, the EKG is in a perfectly normal range as learned by the application. Doctors are alerted when readings slip out of normal range, with raw data transmitted for observation if required. A similar example is waiting for a motor to fail while monitoring its operation.

    Both the LF Edge initiative and work happening in the OpenFog Consortium are creating specifications for edge computing. These initiatives are aimed at interoperable, secure architectures where cooperative processing mines data. If items of interest can be extracted efficiently from useful and ephemeral data at the edge, loads on the cloud and networks would be lighter. Edge computing will likely detect exceptions more quickly, bringing people in to look at what is going on faster. The result will be more scalable IoT applications with better chances of delivering value from all that data.

    — Don Dingee

  • Challenges and Tips for Taking Legacy Systems to the Cloud

    Challenges and Tips for Taking Legacy Systems to the Cloud

    Normalization of infrastructure through open source technologies is one way to make the move to the cloud an easier process for organizations.

    For many modern companies, growth often means growing through acquisition. As organizations become larger, it often makes sense to acquire existing companies who are already creating the solutions they need than try to build them from scratch. However, this can often create a variety of conflicts and challenges—one of which is around infrastructure. For other companies that have grown more organically, it often can be difficult to modernize their legacy systems and bring their technology stack into the 21st century.

    But cloud comes with big benefits: Some studies estimate a cloud-based infrastructure can reduce IT overhead costs by as much as 40 percent while also giving IT leaders a flexible way to scale up and down as needed. It also lends itself well for automation tasks, helping free valuable development time to add meaningful value to applications. And, the cloud isn’t just for tech startups. For example, a recent McKinsey & Company study noted that financial services companies have the highest percentage of server images deployed in private or public clouds, approaching nearly 100 percent (versus a median adoption rate of 19 percent). Cloud is certainly a hot topic, and for good reason.

    In an ideal world, the IT landscape would be a greenfield, where every organization could start with a blank slate and build out their optimum infrastructure. But for most businesses, it is often more of a brownfield—muddied with old systems and stodgy practices—and it’s not always clear the best way to build on top of it. As more and more organizations look to a hybrid cloud approach as the infrastructure mode of the future, the need for a way to migrate legacy systems more easily is becoming an increasing necessity.

    One of the ways to approach this is through the concept of normalization. This is a focus on utilizing industry-leading open source stack technologies that can create a hybrid cloud solution that is consistent and just works immediately: Kubernetes for containers, Fission for serverless functions and OpenStack for VMs, for example. As anyone in IT knows, this goal of normalization is nothing new, but achieving it can go a long way in helping your organization move into the cloud.

    The reason behind this focus on providing a solution that leverages open source technology is the goal of creating this normalized structure that works across different cloud providers. This approach is because all the big three cloud providers have their own special services: Google has TPUs, Amazon has Lambda and Azure has Dynamics CRM. As you move data centers into the public cloud, you still have islands of infrastructure that are all built and run differently. How can DevOps truly have a consistent way of building and operating software in this sort of atmosphere? Open source technologies are a very powerful way to normalize that because they provide a solution that plugs into any infrastructure that you want.

    One of the other keys to help bring your legacy systems into the cloud is to embrace change as it comes. While this is obviously a less technical recommendation than the above, it is still an important component to achieving success. It is no surprise that this sort of approach is one of the main tenets of the DevOps community that dates back to the beginning of the philosophy. It really started with the Puppets and Chefs of the world in the late 2000s and then continued with the rise of the OpenStack community. Finally, containers really started to form, from Vagrant and now to Kubernetes. Along this route, the IT industry has become much more sophisticated and there are a greater number of opportunities to achieve the normalization necessary to ease the transition to cloud—but only if you’re flexible and willing to adapt to change.

    A related important distinction is to understand that complexity exists, and it’s not feasible to eliminate that complexity. Rather, you can take an approach of subdividing it and trying to contain and limit complexity. The strategy of normalization allows you to do this and keep complex parts of your infrastructure isolated as much as possible.

    While there are many approaches to moving legacy systems into the cloud—from rehosting (a lift-and-shift approach) to refactoring (completely re-imagining how the application is architected and developed)—turning your current infrastructure into a cloud by leveraging existing and powerful open source tools is one of the most effective approaches that extract the most value for many organizations. This hybrid cloud approach gives organizations the ability to not only leverage cutting-edge cloud solutions that are agnostic to provider, but also provides a real way for companies to continue utilizing legacy systems that still provide meaningful value for their applications. This flexible, bespoke approach to hybrid cloud enables an entirely new approach to software infrastructure and opens many new doors for sustained success.

    Here’s a full discussion on this topic with Alan Shimel, editor in chief of devopsy.kinsta.cloud, posted on DevOpsTV:

    — Sirish Raghuram