Tag: kubernetes

  • Why Serverless Needs DevOps

    Why Serverless Needs DevOps

    EDITOR’S NOTE: This article was updated July 2, 2018

    Serverless, like Kubernetes and microservices, is a new technology. Yet, despite the amount of blog, forum and news-related posts published about serverless, it represents only a fraction of all IT deployments.

    Aside from the new factor, serverless shares few similarities with Kubernetes and microservices. Organizations turn to Kubernetes and microservices platforms to add more agility and, in many cases, computing power to their IT operations. Serverless deployments, meanwhile, are seen mainly as a way to save resources by relegating server management to third parties.

    Ultimately, cost savings is the main benefit. A successful migration largely hinges on DevOps, especially at the early adoption stage.

    “There are ways to use serverless while delivering a very rich customer experience,” said Sanjay Challa, senior product marketing manager at Datical. “It is about putting the pieces together in a very right way to do that.”

    More specifically, Challa said DevOps is relevant to serverless deployments because:

    • DevOps promotes collaboration between development and operations — a core mantra is “you build it, you run it,” Challa said. “Serverless deployments essentially embody this central tenant: it’s frankly difficult to separate development from operations because any edit to a serverless function needs to be in the context of its operation in the cloud (the cost of the resources the function will incur and the net user experience),” Challa said.
    • With serverless architecture, there is no longer a line between cloud operations engineers and developers. This is because “the roles are collapsed into one, thus embodying the fundamental core of DevOps, to collapse and harmonize the development and operations functions.” Challa said.

    For data and database management, Challa said it’s also important for teams not to forget about the underlying database and data architecture, when moving to the cloud and to new serverless architectures. “If teams only focus on the application code and forget about the database, they are setup to fail as changes to the data/persistence layer simply will not be able to keep up and scale with application changes,” Challa said. “This potentially leads to quality issues, outages or even data loss in the event of a hastily made or erroneous database change.”

    Serverless Not 

    The definition of serverless can vary, but among the many offerings available, it usually refers to functions-as-a-service (FaaS) and backend-as-a-service (BaaS) services. Despite its name, serverless has a lot to do with servers—but organizations delegate the management of those servers and the associated infrastructure to third-party cloud providers. In this way, organizations upload code or applications and the third party maintains and runs the servers. Amazon Web Services’ (AWS) Lambda, Google’s Cloud Functions, IBM’s OpenWhisk and Docker’s Serverless Docker are among the leading offerings.

    When an organization decides to migrate some or all of its data to a serverless platform, it’s important to note the technology’s drawbacks, especially as they relate to DevOps. Common downsides include slower computing performance and less capacity to run code compared to what is available when using servers on-premises or on the cloud. In the case of AWS Lambda, for example, the maximum total of concurrent executions per account is set to 1,000 by default per region and memory capacity for applications is limited to just over 3GB.

    Also, by shifting server management to a third party, organizations also are delegating those management functions, including many associated server-related security and monitoring capabilities.

    Ultimately, it will be up to the DevOps group to weigh the advantages versus the disadvantages when deciding whether to migrate to serverless platforms. While serverless technologies could potentially frustrate some developers because of the performance constraints on computing, memory, etc.; the key issue is to choose the right tool to solve the right problem, Challa said.

    “Each tool has its place,” Challa said. “Serverless is not a cure-all – but is just another tool for enterprises to consider.”

    Job Description

    Migrating to serverless also means job responsibilities will be affected, which will require DevOps to manage. “When you move to serverless, a lot of roles are disrupted. You need your network and infrastructure guys less than you did before, for example,” Challa said. “So, your team will look very different, since serverless teams in general looks very different compared to traditional IT operations.”

    It is also necessary to solve any existing DevOps challenges you have first before you make the switch to serverless, Challa said. “Otherwise, you are setting yourself up to fail,” Challa said. “Without transparency and strong coordination, moving to the cloud and to a serverless architecture will only slow things down—or, worse, lead to outages and quality issues.”

    However, once a serverless platform has been successfully set up and is running, DevOps’ workloads should decrease, since there will be less server maintenance work to do, said Holger Mueller, an analyst for Constellation Research.

    “With FaaS, DevOps is less relevant as deployments take place within the FaaS framework,” Mueller said. “There is no need for DevOps to write scripts or manually do anything. Normally, everything should just run itself.”

    However, Challa disagreed that serverless deployments completely run on their own once deployed. “Someone had to set up and configure a pipeline to enable developers to validate, build and ultimately deploy their serverless code. That someone must also play a DevOps function in enabling a path from a developer’s workstation to the cloud that supports the serverless capabilities—not to mention the work that needs to be done to connect the serverless application code running in the cloud to meaningful data,” he said.

    — B. Cameron Gain

  • Developer Trend Chat: Microservices, Node.js, Kubernetes

    Developer Trend Chat: Microservices, Node.js, Kubernetes

    The role of software developers has never been more important. Developers touch almost every corner of our lives, from health care and retail to education. It’s an extremely rewarding career—so much so that software development is now ranked the Best Job in the United States.

    The nature of software development demands that developers be fast-moving. New tools and technologies are providing developers the ability to adopt new skills, work faster and reshape how they work. In this Q&A, CEO of LunchBadger Al Tsang discusses trends in software development.

    Q: Data distribution is still a difficult and complex aspect of breaking down a monolithic architecture. How can enterprise architects avoid this or what is a good strategy for dealing with this snag when they will encounter it eventually?

    Al Tsang, CEO, LunchBadger

    Al: The data’s location, its dependencies and varying levels of data normalization, make breaking down monolithic architectures a challenge. Microservices initiatives can address these challenges by constructing a comprehensive data model. In the past, we had UML tools such as ERD diagrams. These tools are not as common anymore, however, the practice of what they represent still brings value in understanding what data your applications currently use, what’s obsolete, what’s redundant, and what’s related with dependencies.

    Microservices and the tie in to data should be atomic enough so that the data that it operates against is wholly owned and contained. This is easier said than done. There are often dividing lines that can be carved out that mirror the business functionality itself—whether that be by domain, by entity or by business process. In some cases, it’s a combination of all the above.

    Q: Why do you think serverless and FaaS (functions as a service) is growing at such a rapid rate and what specific pain points do serverless platforms (such as LunchBadger) address?

    Al: I believe serverless and FaaS is growing rapidly for a number of key reasons:

    (1) Infrastructure and application platform [are] becoming highly commoditized where a developer can pass the buck to have operational concerns placed on a third party.

    (2) The pressure and need to innovate requires an intense focus on working on your core IP as a differentiator while everything else in your code is a supporting role and oftentimes something that is completely boilerplate (e.g. think persistence to a database or NoSQL data source).

    (3) The movement and drive behind attaining microservices means getting down to bite-sized pieces of functionality means whittling down your logic do distinct reusable compartmentalized pieces of code—i.e., functions—and “serverless” fits this paradigm nicely by adding that you should only concern yourself with the piece of code on an event driven basis.

    (4) New and old companies alike have amassed a zoo of technological languages and platforms where skill sets and resources can be more efficiently utilized if you have a common runtime paradigm and can write your business functionality that supports polyglot usage.

    Q: According to a survey in 2017, Node.js was primarily used as back-end infrastructure for APIs. One of the main strengths of Node.js is that you can use the same language on the entire stack. How do you think Express.js and other minimal frameworks like it contribute to its popularity and why?

    Al: One reason Node.js has had rapid and wide adoption is because it is a massive equalizer. Node.js developers don’t need to have ninja-level domain expertise in high scalability, multi-concurrent connectivity, threads or similar complex topics just to be able to build a scalable app.

    Node.js takes advantage of a language that had the principles of high scalability built inside, namely evented asynchronous programming. Node.js also has an advantage as it’s the language that any web developer would have exposure to thanks to the ubiquity of browsers. Moving the same language and its strengths to the server was a huge win for folks to truly become “full stack.”

    Express.js has further contributed to Node.js’ success by adding the basics of web utility to Node.js. Every web application needs a web/app server that exposes URLs as routes. All servers have consumers making requests and processing those requests can often time be chained from one piece of logic to another. Express took the learnings from Ruby and Sinatra and brought them to Node.js.  You scaffolded a template project and filled in the blanks, as needed and where needed. It’s highly productive because the starting point for many web applications follow this same model.

    Express Gateway galvanizes the success of Express.js—its rich ecosystem of middleware modules and ubiquitous understanding among many developers and make its cloud ready and cloud native by separating out the configuration, metadata and conditionality to be declarative and dynamic. By doing this, Express Gateway runs in containers and orchestrators in a distributed way without worrying about being coupled at any given tier of the application.

    Q: Node.js and Kubernetes is a popular combination, but many developers and companies are confused on where to start or how it will affect their tech stack. Can you explain the top roadblocks you’re seeing and how companies can overcome them?

    Al: Roadblock #1: Where should you extend Kubernetes or where should you extend your Node.js application?

    I think this entangled mess is actually not as bad as it’s often perceived it to be. If it’s a core part of your application and you’ve written it in Node.js, then it should be completely independent of where and how you run it. Before the wide adoption of containers, many Node.js applications were being run in process managers. Many are still running in process managers within a container. In short, if it’s a core piece of your application logic, it should be in Node.js. If it concerns how and where you run the application logic, now you’re looking at configuration or extensions within Kubernetes.

    Roadblock #2: Should I use Node.js to orchestrate my application or leave that to Kubernetes and why?

    Orchestration means wiring up your application at the infrastructure level. Leave this piece to Kubernetes, which can expose and manage your microservices truly as “services.” When you’re writing Node.js applications, you shouldn’t have to worry about the “I/O” of how different Node.js processes interoperate. The whole premise behind microservices is that there are distinct lines drawn where processes must interoperate without assuming the other process may even be up and running.

    Roadblock #3: What if I have a component that has both infrastructure AND application concerns?

    This is a tough one where a lot of companies, large and small, are feeling pain. Kubernetes has a notion of an ingress controller, which is really nothing more than routing and exposure of requests externally to a resource designated internally to handle it somewhere with the Kubernetes cluster. This raises the question: Should you put application-level concerns on that ingress controller?

    I believe in a clean separation of concerns, even if that means having some runtime overhead. If your business requirements don’t require super low latency or other cases that drive you to blur the lines between infrastructure and application, then it’s much easier to maintain if there is a clean separation. This is really no different than slicing and dicing your application into smaller microservices. It’s just executed in your stack at a horizontal rather than vertical level. Build an ingress controller that is only concerned about routing to the right resource. Then build a separate API gateway that sits in front of the microservice(s) to take care of application-level concerns.

    — Malia Powers

  • Jump-Start Your Kubernetes Journey with JenkinsX

    Jump-Start Your Kubernetes Journey with JenkinsX

    Containers are very quickly being adopted as the stable way of deploying services. More and more organizations are adopting immutable architecture and containers provide an excellent way to achieve that.

    But along with the stability comes the complexity of deployment, along with managing workload, scaling and updating. That’s in addition to having to create a reliable and repeatable process to continuously build and ship these containers to a production ready state. Kubernetes is one option: It provides features to reliably manage production workloads for your services.

    So now developers have to learn Kubernetes, as well as how to prepare their application for Kubernetes and create the pipeline for continuous integration and continuous deployment (CI/CD). Developers also must determine what is the best approach to get this done and where to start.

    JenkinsX: CI/CD for Kubernetes

    JenkinsX is an open source CI/CD solution for the modern cloud platform for developing and managing applications on Kubernetes. It’s the automation that helps an application move to Kubernetes, deploying various services on Kubernetes to manage an application’s CI/CD journey.

    Developers simply focus on their product and its features and JenkinsX will manage the Kubernetes deployment. It’s opinionated yet flexible, and provides extensive customization. Users can create a Kubernetes cluster using JenkinsX on AWS, Azure, Google or even locally on minikube or minishift. Developers who already have their own Kubernetes cluster and its RBAC (Role Based Access Control) enabled can simply install JenkinsX on top of it.

    JenkinsX provides various templates, and, since it’s open source, more templates are added daily. Developers can do a quickstart with a templated version of spring boot application, a golang project, node, open-liberty, python-http and more. It will create a git repo for a template application and then connect to developer’s github account to push this template to a repo. Also, it sets up the required webhooks to talk to Jenkins, which is installed on Kubernetes as part of the JenkinsX setup.

    JenkinsX also creates namespace environments in Kubernetes. By default, it will create a staging and production environment that can be modified.

    Once changes are made to a templated quickstart application and a pull request is created, the process kicks in and pushes the payload using webhooks to jenkins. The pipeline jobs then kick in to start the build process.

    After the application builds in its own container, the next stage begins to create a docker image and push it to the internal docker registry. Helm charts are generated for the application and stored in the internal hosted chart museum. It is then deployed to a preview environment and developers can view or run tests against the application even before the pull requests are merged.

    As the pull request is reviewed and merged to the master branch, a job kicks in to deploy that application on to the environments. JenkinX implements GitOps, so any and every change is triggered from the github repository. It creates a pull request to the environment repository and adds a change to deploy this application in this environment., validates the pull request and automatically merges it, kick-starting the final deployment stage.

    An environment is mapped to a specific namespace, the application container is then deployed in that namespace, a service is created and all the required mappings are configured. Also, a URL is spit out for developers to hit their application.

    Developers then push their changes, grab a coffee (this step is optional) and few minutes later they get the URL to access the application in that environment.

    That’s the standard workflow. As you might have noticed, JenkinsX is very different from the traditional Jenkins approach. Jenkins provides complete flexibility, whereas JenkinsX provides an opinionated approach. Given everything is in the template repo it creates, you can always modify them to your requirements.

    A Jenkinsfile is created for the pipeline jobs that can be edited to add another stage. Helm charts are created and can be updated if required. Users can disable the default environment it creates the first time and have their own set of persistent or disposable environments.

    This is a great approach toward automating of various different tools we use today to build and deploy our applications on Kubernetes. There are a few features I would love to see added, such as different deployment strategies, support for internal docker registries and maintenance features to clean up obsolete images. That said, JenkinsX removes much of the learning curve and jump-starts your Kubernetes and container journey.

    — Saurav Sen

  • NeuVector 2.0 Automates Kubernetes Security Incident Detection and Response

    Release enables enterprises to deploy Kubernetes with confidence by automating security and adding protection from new threat vectors

    San Jose, CA – April 12, 2018 – NeuVector, the leader in Kubernetes security delivering the first and only multi-vector container firewall, today announced NeuVector 2.0. The enhanced security solution further protects Kubernetes environments by building on the unique NeuVector run-time security automation, which combines east-west traffic visibility with container process monitoring and vulnerability scanning. NeuVector 2.0 adds important new capabilities that include a Kubernetes incident response system alongside advanced process and file system protections to secure against new attack vectors.

    NeuVector 2.0 will be available for demo at RSA Conference 2018 in San Francisco, April 16-20 (booth #4910).

    Enterprises require fast and decisive responses when security incidents and potential attacks occur within Kubernetes deployments. NeuVector 2.0 deploys within an organization’s existing security processes to rapidly address and mitigate ongoing container threats. When NeuVector detects threats and vulnerabilities, the new auto-response rules – built to address common container attacks and security alerts – instantly provide response actions to protect containers and generate alerts.

    These rules can also be customized to match criteria such as specific container vulnerability profiles, or set to address suspicious activity across multiple threat vectors – including the container network, processes, or file system. NeuVector 2.0 provides a unique range of incident responses, with full capabilities to quarantine compromised containers, generate custom notifications, and whitelist non-critical events. Using NeuVector 2.0, enterprises can fully address container security events and protect their applications, container services, and infrastructure from multi-vector attacks.

    NeuVector 2.0 also adds new automated protections that detect exploits within containers, such as suspicious processes or file system activities. The security solution automatically calculates a baseline of container processes, whitelists legitimate activity, and alerts on any deviation from the baseline. Any installation of malicious packages, libraries, or new executables – or any modification to sensitive files – triggers NeuVector to scan the container for vulnerabilities and alert on the suspicious activity. These automatic protections do not require configuration but do allow for easy customization of whitelist/blacklist rules as desired. The new capabilities bolster NeuVector’s multi-vector firewall by adding deeper insights into activities within Kubernetes deployments, further safeguarding containers from process and file system attack vectors.

    “The highly dynamic nature of Kubernetes environments makes robust and responsive threat automation a critical requirement to enterprise security,” said Fei Huang, CEO, NeuVector. “The release of NeuVector 2.0 offers rapid detection and response that addresses security threats as they occur, while protecting systems from process and file system-based attacks. We focus on continually automating the real-time security of Kubernetes deployments for enterprises using our solution.”

    About NeuVector

    NeuVector is the leader in Kubernetes security and delivers the first and only multi-vector container firewall – which enables the confident deployment of enterprise-wide container strategies across multi-cloud and on-prem environments. NeuVector provides east-west container traffic visibility, container protection, and host security in a highly integrated, automated security solution. Customers include global leaders in financial services, healthcare and publishing, and the company is partners with AWS, Docker, IBM, Rancher, Red Hat, and others. Founded by industry veterans from Fortinet, VMware, and Trend Micro, NeuVector has developed patent-pending behavioral learning for container security.

    ####

  • DevOps Gets More Exciting in 2018

    DevOps Gets More Exciting in 2018

    As 2017 winds down and the IT industry prepares for 2018, there are a number of DevOps trends that everyone should be keeping their eyes on. It’s not so much that something incredible and explosive is expected in the new year. Rather, 2018 will be a time when DevOps starts to mature alongside other trends important to developers.

    These trends don’t guarantee organizations will be immediately successful with DevOps. Most still will struggle with the management aspects of DevOps, especially the need to keep feuding silos within IT working together as one happy group. Assuming developers, QA, and Operations can all learn to get along and act as a team, the technology supporting DevOps will continue to improve and the ecosystem will grow.

    Here are some of the DevOps trends that Amalgam Insights is following for 2018:

    Everyone Loves Containers and the Ecosystem Grows

    Containers have become a common technology in many IT departments. Although the majority of applications remain housed on single servers and virtual machines, container deployments are growing. Containers are an important enabling technology for DevOps—by creating small, transportable bits of applications, containers make it easy for IT silos to work from the same page.

    In 2018, growth in container deployments is expected to accelerate as large companies outside the software industry, such as those in financial services and health care, adopt microservices infrastructure. Containers that are especially suited to microservices will continue to expand rapidly.

    Increased container growth is also due to an expanding ecosystem. More companies have entered the market with products necessary to large-scale production applications. Products now exist for securing, managing, deploying and enhancing container services that weren’t available a few years ago. What’s more, containers are now available in all the major cloud services including Oracle Cloud, Microsoft Azure, AWS, IBM Cloud and Google Cloud. Containers are becoming enterprise-ready and large enterprises are feeling more confident using them.

    Takeaway: Growth in the ecosystem contributes to growth in container deployments while expansion of containers entices companies to enter the ecosystem. Containers have reached mainstream normalization and we expect to see fast expansion throughout 2018.

    Kubernetes Eats the Container Orchestration World

    In the container orchestration space, Kubernetes has become the tool of choice. Orchestration is the deployment and management of container clusters and is necessary to deploy them at scale. Kubernetes, originally a Google open source project and now managed by the Cloud Native Computing Foundation, has become the most popular orchestration tool available. That became obvious when Docker decided to distribute and support Kubernetes, despite having invested in its own orchestration system called Swarm. CoreOS, Microsoft Azure, Red Hat OpenShift, Docker and others have their own enterprise distributions as well.

    Kubernetes brings to the container ecosystem a relatively easy way to manage containers at scale. In large container deployments, containers are constantly being spun up, shut down, moved and copied. Once container clusters are in place, they must be monitored for security and service failure.

    During development, there will be a number of clusters that must be managed for development, test and final release to production. Doing this manually is close to impossible when even a moderate number of containers are in the DevOps pipeline. Kubernetes provides the tools and workflow to simplify these tasks.

    Takeaway: As container production clusters grow and as they are integrated into the DevOps pipeline, the need for orchestration becomes acute. Kubernetes has won the game and is now the tool of choice for orchestration. 

    The Pipeline is Getting More Integrated

    DevOps is often described of as a “pipeline,” In this context, a pipeline is a linear workflow that moves from build to test to release. As DevOps becomes more common in organizations, the pipeline grows to include additional test phases, monitoring and continuous improvement to create more of a cycle than a linear flow.

    One of the great impediments to making DevOps a reality is a lack of tools that support the entire pipeline. There are plenty of tools that help build applications, such as IDEs and code repositories from companies such as IBM, Microsoft, GitHub and Oracle, as well as dozens of open source products. Testing is well-supported with test data management and test plan management tools from companies such Atlassian, Informatica and Oracle. Release management and deployment products are widely available from Atlassian, Microsoft, IBM and many other companies. The problem lies not with the support for the individual steps in the pipeline, but with the integration of these tools to provide a complete end-to-end workflow. This creates a disjointed workflow, prone to errors and supportive of silos instead of collaboration.

    This is changing, however, and announcements late in 2017 herald toolsets that can provide a continuous DevOps pipeline. A great example of this is the newest versions of Microsoft’s developer tools that were debuted at Microsoft Connect(); in November 2017. Tying together the Visual Studio debugger with Kubernetes allows developers to test and debug as close to the production environment as possible and then deploy cluster to the test environment. That, plus the upgrades to Team Server, shows the commitment Microsoft has to creating integrated DevOps systems.

    Takeaway: While DevOps tools are still more or less disjointed, we are seeing a movement to fully integrated toolsets that enable the end-to-end DevOps pipeline.

    2018 is the Year of DevOps—Unless IT Management Gets It Wrong

    This coming year could be the year that DevOps truly takes off and becomes mainstream. Those who believe it is already mainstream now are fooling themselves. Management may believe their organization is implementing DevOps, but too many barriers still exist—especially management itself. IT departments remain heavily siloed and independent of each other, as do development tools. DevOps at scale requires, above all else, a collaborative and cooperative approach. Sadly, that does not yet exist in many IT departments. As tools reach maturity and best practices become common, managers become the inhibitors of DevOps. New management structures, incentives and thought processes need to be in place or the money spent on tools is wasted.

    Takeaway: All the DevOps pieces are in place except for the breaking down of functional silos that exist in IT departments. 2018 may be the year of DevOps if IT managers can create a new environment of cooperation.

    About the Author / Tom Petrocelli

    Tom Petrocelli is a contributing analyst with Amalgam Insights. His area of interest is collaboration and new ways of work, developer tools, IT project efficiency, governance and methodologies and DevOps. Most recently, Tom worked for a large, global banking corporation. Previously, he was the research director for Enterprise Social, Mobile and Cloud Applications at Neuralytix. He is an experienced marketing, technology and business executive with 30+ years in the computer technology industry. Tom’s background spans software engineering, systems architecture, IT, product management and marketing and general management. Connect with him on LinkedIn and follow him on Twitter.

  • Morpheus Data Advances DevOps Across Hybrid Clouds

    Morpheus Data Advances DevOps Across Hybrid Clouds

    Thanks to the rise of multi-cloud computing, the challenges associated with managing DevOps are becoming exponentially greater. Most IT organizations are not likely to be 100 percent sure at any given time which application workload is running where.

    To address that issue, Morpheus Data has added a Cross-Platform Discovery module to its Unified Ops Orchestration platform that employs machine learning algorithms to determine not only what applications, virtual machines and containers have been deployed on-premises or in a public cloud, but also how much capacity, memory usage and power consumption each is using and their and overall performance.

    At the same time, Morpheus Data is adding integration with Github and Jenkins continuous integration/continuous delivery (CI/CD) environments as well as support for both Docker Swarm and Kubernetes clusters.

    Finally, Morpheus Data has added connectors to IBM Cloud, Upcloud and HPE OneView services and been certified as a ServiceNow partner. The Unified Ops Orchestration platform already supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform.

    Brad Parks, vice president of marketing and business development for Morpheus Data, notes that as IT environments become more distributed in the age of the cloud, new approaches to change management will be required. The Unified Ops Platform provides an opportunity to consolidate change management processes within the context of a single control plane.

    While more IT organizations are making use of multiple cloud services, most are managing each IT environment in isolation. Over time, the lack of unification of the control planes for each of those environments conspires to increase the total cost of ownership for IT. Morpheus Data is making a case of for unifying the management of multiple platforms running on-premises or in public cloud instead of requiring IT staff to master multiple management tools.

    That single management plane, Parks says, also makes it much easier for IT organizations to take dynamically employ multiple cloud environments. Price points for cloud services are liable to change at any moment, but it doesn’t necessarily follow that the same type of workload will continue to be deployed on the same cloud. At the same time, the characteristics of a workload may have evolved to the point where it doesn’t make financial sense to deploy it on a public cloud. A common management platform makes it possible to move that workload with the least amount of disruption possible.

    Most IT organizations today are concerned about getting locked into a cloud service provider. Being able to demonstrate an ability to switch between cloud service providers gives IT organizations an opportunity to negotiate cloud service contracts from a position of strength. Most cloud service providers are counting on the fact that the cost of switching from one provider to another is simply too high. Integrated DevOps processes wrapped around a common management plane, however, will make it clear to all concerned that the platform provider serves at the pleasure of the internal IT department, not the other way around.

    — Mike Vizard

  • Kubernetes is the Universal Cloud Infrastructure

    Kubernetes is the Universal Cloud Infrastructure

    Before I started Rancher Labs, I created a company called Cloud.com where we developed Apache CloudStack. We were inspired by the early success of Amazon Web Services (AWS) and wanted to make it possible for everyone to stand up AWS-like cloud infrastructure for themselves.

    While CloudStack was successful in powering a number of public and private clouds, it failed to achieve mass adoption. Instead, cloud infrastructure today is increasingly concentrated in a small number of very large public cloud providers such as AWS and Microsoft Azure. There are a few reasons for this:

    1. It takes a lot of capital investment and operational expertise to operate cloud infrastructure. Only large players can benefit from economy of scale.
    2. There is no consistency among different cloud infrastructure providers. Even if a smaller provider can beat an established player on price, it becomes increasingly difficult for customers to migrate workloads from one cloud to another.
    3. The scope of cloud infrastructure services is forever expanding. It is no longer sufficient to offer basic compute, storage and networking services. Leading providers such as AWS offer an ever-growing number of services for data processing, analytics and artificial intelligence.

    Despite the downside of cloud lock-in, organizations are facing increasingly fewer choices in cloud infrastructure as they adopt cloud computing.

    Enter Containers and Kubernetes

    We started Rancher Labs because we saw that containers can potentially change the game in cloud computing. Docker is a universal application packaging standard that makes applications portable. Kubernetes adds cluster management to Docker. Many people think the power of Kubernetes lies in its ability to manage applications and microservices. We completely agree. We believe, however, that Kubernetes also brings significant benefit by hiding the differences between cloud infrastructure providers. Kubernetes comes with a rich ecosystem of plugins for storage, networking and load balancing. As a result, it does not matter where you have deployed Kubernetes. As long as the drivers are configured correctly, users get a consistent view of cloud infrastructure regardless what cloud provider they use.

    In addition to offering consistent storage, networking and load balancing, Kubernetes also brings with it a rich ecosystem of higher-level services for developers. The Cloud Native Computing Ecosystem includes all major providers of system- and platform-level software. Kubernetes has become the center of gravity of innovation in cloud computing. New capabilities are made available at a faster pace than anywhere else.

    In the early days, it was quite challenging to setup and run Kubernetes. Companies such as Rancher created Kubernetes distributions that make it easy for DevOps and IT teams to deploy and operate Kubernetes clusters. Today, many cloud providers offer Kubernetes as a service. At Rancher, we are now more focused on managing Kubernetes clusters. We expect most, if not all, major cloud providers to support Kubernetes in the future. When that happens, Kubernetes will be the universal cloud infrastructure.

    If you use cloud computing, there is no reason not to use Kubernetes. You get the most complete ecosystem support and the same consistent experience no matter where you go. Cloud lock-in will be a thing of the past.

    About the Author / Sheng Liang

    Sheng is a co-founder and CEO of Rancher Labs. Prior to starting Rancher, Sheng was CTO of the Cloud Platforms group at Citrix Systems after their acquisition of Cloud.com, where he was co-founder and CEO. Sheng has more than 15 years of experience building innovative technology. He was a co-founder at Teros, which was acquired by Citrix in 2005 and led large engineering teams at SEVEN Networks, and Openwave Systems. Sheng started his career as a Staff Engineer in Java Software at Sun Microsystems, where he designed the Java Native Interface (JNI) and led the Java Virtual Machine (JVM) development for the Java 2 platform. Sheng has a B.S. from the University of Science and Technology of China and a Ph.D. from Yale University. Follow him on Twitter.

  • DevOps Chat: Aqua Security Seeks To Secure Containers

    DevOps Chat: Aqua Security Seeks To Secure Containers

    The migration to container-based application infrastructures is accelerating at a faster pace even than we saw with hypervisor-based infrastructure 18 or so years ago. Hand in hand with this is the race to provide better security solutions that are native to and purpose-built for containerized environments. Aqua Security has established itself in the container security arena, recently raising $25 million in capital funding as it seeks to lock down the container security market.

    In this chat, we sat down with Rani Osnat of Aqua Security to discuss the recent funding round and the state of the container security market. Below is the streaming audio of our discussion. Below that is the transcript of our discussion.

    Audio

    Transcript

    [su_pullquote align=”right”]Rani Osnat[su_custom_gallery source=”media: 1739530″ width=”100″ height=”100″ align=”center”]
    Rani Osnat has more than 20 years of enterprise software industry experience, in project management, product management and marketing, including a decade as VP of marketing for innovative tech startups in the IT security and cloud arenas. Previously Rani was a management consultant in the London office of Booz & Co. He holds an MBA from INSEAD in Fontainebleau, France. Rani is an avid wine geek, and a slightly less avid painter.[/su_pullquote]

    Alan Shimel: Hi, everyone. This is Alan Shimel for devopsy.kinsta.cloud and Security Boulevard, and welcome to another chat.

    Today’s guest is Rani Osnat, VP of Marketing for Aqua Security, one of the leaders in the container security market, and Rani, welcome to our DevOps Chat.

    Rani Osnat: Thank you, Alan. Thanks for having me.

    Shimel: Thank you. Thank you for being here. So, Rani, the big news out of Aqua recently is, by anyone’s yardstick, a large raise of capital to fuel Aqua’s continued growth.

    Osnat: Yep, that’s correct. We raised $25,000,000.00 in a series B round led by Lightspeed Venture Partners, which is a very well-known tier one VC.

    Shimel: Yep.

    Osnat: And, it’s—well, to the best of my knowledge, it’s the biggest funding round in our space in continuous security to date, and it also brings total funding for us to $38.5 million.

    Shimel: That’s fantastic.

    Osnat: So, we’re, I think, in a pretty good position to capture what we think is a tremendous opportunity in this market.

    Shimel: Sure. And so, Rani, we were talking off mic prior to recording today—you know, beyond the sheer magnitude of the number, right, 25 is a big number, 38 is a bigger number—but beyond that, there’s also the validation. Which is, you assume a company like Lightspeed Ventures, Microsoft Ventures is another investor in the company, Shlomo Kramer, of course, from Check Point is another investor. You would assume these people are pretty bright people and they don’t throw their good money away. That, if they’re investing this money, they invest it for two things. No. 1, they see the opportunity in the market, so the market itself is ripe and worthy of that sort of investment. And then No. 2, that the team and the product at Aqua are also worthy of the investment.

    Let’s first talk about the market, if we can, though. I mean, so this is a validation, I think, of the container security market, if you will, right?

    Osnat: Yeah.

    Shimel: The containers are real, that securing them are real, and there’s gonna be a big market for that coming up. What do you think?

    Osnat: Yeah, I mean, definitely, when we started Aqua just under two years ago, we didn’t quite know how fast the market would move and what kind of market it would shape up to be. And fairly early on, even when we were in beta in early 2016, it became fairly obvious that this is an enterprise market. That is that, you know, some of the biggest adopters of container technology are not just Silicon Valley startups or web-scale companies that kind of invented this, but Fortune 500 enterprises across verticals like financials, insurance, retail, aerospace, manufacturing, and so forth, as well as government.

    And so, paradoxically, you would expect this kind of new technology to be first adopted by startups, but the real boom in adoption comes from the fact that enterprises are adopting it very quickly, and I think there are several reasons for that. One is that the benefits of using containers are overwhelmingly positive, and the benefits are pretty immediate. So, you can see benefits in agility in terms of how fast you can deliver applications to the market, you can see benefits in moving to the cloud, and reducing your infrastructure costs and operational costs. And you can see much better control over what kind of applications you’re deploying, where, and when, et cetera, largely through automation.

    So, these benefits are overwhelming, and additionally, containers are easy, right? So, it’s—you know, one of the things that made containers, which in itself is not a new technology, it’s been around for a while, but what companies like Docker did is make containers very accessible and very usable. And so, the fact that they’re easy to use makes adoption easy as well, and you know, you kind of see a pincer movement of, on the one hand, grassroots adoption through developer and DevOps teams of containers, so they develop applications using containers. And on the other hand, you’re seeing a top down approach of, you know, CIOs, CTOs seeing the benefits of containers, adopting them, or mandating their use for, for example, cloud native applications to drive cloud usage, hybrid cloud, cloud migration—all of those good things.

    Shimel: Absolutely. So, Rani, you know—granted, I’m not as involved in container and container security as you are, obviously, but to me, a couple of different thoughts. Number one, in my limited—granted, limited expertise, containers aren’t that easy, right? I mean, I think when we talk about containers and then, like, Kubernetes and stuff to manage the whole environment—for someone who hasn’t developed on them before and is used to developing, let’s say, in VMware or in Bare Metal, there is, there’s a learning curve. Maybe once you pick it up, it’s easier.

    But the other thing is, I always try to compare sort of container adoption, let’s say, to hypervisor adoption or VMware adoption, and I would say that containers, their adoption curve is higher or steeper, faster than sort of hypervisor’s.

    Osnat: Yeah, that’s correct.

    Shimel: And really what I see, the last couple—you know, we’re always doing surveys here at devopsy.kinsta.cloud, announcing the new Security Boulevard site—what we’re seeing is, you know, we always saw people messing with the containers, right? R&D testing, what have you—but the numbers of containers, the percentage of companies that have containers in product deployment, you know, in real, frontline stuff? Where it was—jeez, just two or three years ago was low teens, below 20 percent—is now climbing, getting near that critical mass number, right, of 50 percents and stuff like that. And that’s huge, right? You’re talking about early adopters moving to mainstream in a matter of months, and that’s —

    Osnat: That’s correct.

    Shimel: — that’s the numbers you see as well?

    Osnat: Yeah, we see that. And again, I don’t think this would’ve been the case if containers weren’t easy, as I said. I mean, there’s always a learning curve with new technology, but I think if you’re a new developer, a new programmer working today, working on a greenfield application, there’s really no reason for you to use something that is not containers unless it’s something obscure for technology reasons.

    But mostly, it’s a much easier way to develop applications quickly than previous approaches. And I think, you know, if we take a broader picture, a container is—this adoption of containers does not occur in a vacuum, and we actually see a convergence of three trends that are kinda coming together and containers are probably the biggest enabler of those three trends. And these trends are happening independently of each other. So, you know, one trend is one that you are very familiar with, it’s the name of your site, is DevOps, you know, the proliferation of DevOps as a method, process, organizational philosophy, et cetera, which is all about delivering applications faster and in a more continuous way, and containers make that easier than before.

    Another trend is the move to microservices architectures, you know, for web applications or cloud native applications, which is basically adopting what web scale companies like Facebook and Twitter and Netflix started, and now bringing into the mainstream. That, too, is facilitated to a great degree by containers, because implementing microservices as containers is, today, probably the easiest method of doing that. I mean, there are the so—called serverless architectures, et cetera, but they’re much less mature than containers are at the moment. Not that containers are super mature, but they’re more mature.

    And the other aspect is the whole kind of hybrid cloud, cloud native movement where, you know, it took 10 years, but enterprises are adopting cloud services in a very big way, including industries that you would never dreamed of having on the cloud, on the public cloud, like pharmaceutical, health care, insurance, banking, federal, and so forth.

    So, all of these—and again, containers, because they’re portable, because they can run anywhere in the same way, they’re a really good way to realize this notion of hybrid cloud. For example, we at Aqua have a customer—who, unfortunately, I can’t name, but it’s a well-known company. And they are, for them, this is already a reality. They are deploying applications on both Amazon and Azure using the same framework, using the same security policies, and in a way that makes these clouds interchangeable for them, so they can run application A on Azure today and they can run the same application on Amazon tomorrow. So, that’s a real change that we see, and containers are a big part of that.

    So, all of these things together, I think, are what’s driving this adoption. And yet, you know, I think we have to distinguish between adoption and penetration or, you know, maybe some other word. But the fact is that today, if you look at the total workloads that enterprises are running, containers are a very, very small percentage of that. But, if you look at any new applications delivered over the next five years as well as looking at migrating legacy applications to the cloud, you’ll see this number growing exponentially over the next few years.

    So, yes, in terms of the number of enterprises now either looking at, working with, or already deploying containers, that number is growing very fast, and I think there’s probably hardly a large enterprise on the planet today that is not at least thinking about containers if not already using them. But at the same time, you know, it’s early days for them. Most of them—not all of them, but most of them, the vast majority are looking at the first few applications being deployed, and this is just the first drop of rain before the deluge. So, it’s gonna be a lot bigger.

    Shimel: Yep. Rani, a couple of comments, questions, follow ups. So, first of all—yes, DevOps, containers, they seem to go like peanut butter and chocolate. Again, so does microservices and containers, but to me, I—you know, when I was a kid, a teacher once taught us that all spaghetti is macaroni, but not all macaroni is spaghetti.

    Osnat: Sure.

    Shimel: So, it almost seems that, you know, wherever you see containers, you see microservices, but you don’t always see containers when you see microservices, right? In some regards, microservices can be even bigger, right? It has even more of a use footprint. Actually, on devopsy.kinsta.cloud, we’re launching a microservices channel which we hope will eventually grow into a standalone site, because I do think microservices is that big and has the potential to be that big.

    Osnat: Yeah, but microservices is not a technology; containers are. Microservices is an architecture, you know what I’m saying? There’s a difference.

    Shimel: Yeah, fair enough. Yep. But, you know, bringing it back—and, of course, loud usage and all of that. But, let’s turn for a moment and talk about the mission of securing containers and all of these architectures and platforms and so forth. That’s really what Aqua is, and when we talk about why they invested money, these investors, not just because the containers are so big, but because the mission of securing them is also big.

    Osnat: That’s true. So, yeah, I mean, when you look at—so, first of all, we’re not really, I mean, the fact that we’re a container security company might allude to the fact that we secure containers. That’s not exactly true. So, you know, we don’t look to secure a container or containers, we look to secure the workloads or applications that are running on containers.

    Shimel: Mm-hmm.

    Osnat: And that’s a difference. Because—and again, here, there are several trends that come into play. One is really that these things that I mentioned before, the DevOps trends, the microservices, architecture, and moving to the cloud, they also affect how you can and want to do security. You know, if we look at the cloud first—when you go to the cloud, a lot of the basics, you know, the bread and butter security that you use to invest in as an enterprise disappears. Why? Because these are services that are already taken care of or provided by the cloud service provider.

    So, you know, when you run your applications on Amazon, you don’t really have to worry about things like data center security, infrastructure security, network security to a degree, identity management to a degree. And so, a lot of these things are—you know, they’re basically taken care of for you. So, the focus shifts to the application layer, and that is one aspect.

    Another aspect, which is a really positive one for using containers, is the fact that, since you are now breaking up the application into a bunch of microservices, you can have much more visibility and control into what the application is doing. You know, if you look at an individual container or microservice, it’s much easier to understand the intended function of that container or service, and consequently, be able to understand what is considered good behavior, and be able to identify pretty easily what is bad behavior. And you do that at a very granular level.

    Additionally, if you look at the networking aspect, in a way, the networking has been brought into the application in a more visible way than before. Before, you could have things done within the application that maybe a malicious actor did within the application, and it’s all done internally, and it’s a black box. You don’t have visibility into it until it actually gets out.

    With microservices, you are able to see the interaction between the different components of the application, sometimes at a very fine grained level and, again, be able to identify any kind of weird or abnormal communication between, you know, parts of the application that are not supposed to be communicating that way. So, that’s another benefit. So, these things really allow us to have much more control and visibility over what the application is doing.

    The last piece is around DevOps, which is often nowadays coined as DevSecOps, which is the whole notion of shifting left security—i.e., bringing some of the control points not to the run time environment but to the developer environment. And why is that? Because containers are also immutable, right? So, if you’re using containers directly, you’re not supposed to see any change in one time environments. You’re not supposed to see patching, nobody is supposed to SSH into your host that’s running containers, it’s supposed to be entirely orchestrated and automated.

    And so, anything that happens there is by definition not good. But, at the same time, you have the opportunity to make the application more secure from the start, which is in the development phase, and that includes things like, you know, removing vulnerabilities, ensuring the configuration is correct, enforcing best practices. And if you can automate that—which we do—then you’re winning, right? Because you’re delivering a much more secure application to start with, you’re gonna have a smaller attack surface, and then in run time, all you need to do is make sure that there is no drift or no unexpected changes to the run time environment, which would be considered malicious or at least suspect.

    Shimel: Got it. So, Rani, we’re running a little low on time. We’re actually out of time, but let’s keep talking. [Laughter]

    Osnat: [Laughter]

    Shimel: So, now, we’ve got—what are you gonna do, how are you using the 25 million? What’s the plan?

    Osnat: Right, so you know, in our short life of two years, we managed to launch the product very early and get quite a few enterprise customers, many of them Fortune 100 customers across many industries, and that sort of traction is what really made Lightspeed and the other investors invest in us, and we need to continue this. The market is growing, right? As we mentioned, adoption is growing at an accelerated pace, so we need to be there.

    That means, you know, investing in the quality as well as the breadth and depth of our solution. There is—containers are not a singular technology. I mean, there’s a lot of variation in the stack, not just in orchestrators and OS’s, but in the container engines themselves, and this will become even more so over the next few months as things like, you know, additional run time engines are introduced, and not just the Docker open source run time engine.

    And so, this requires investing in the right technologies and making sure that we can fulfill the requirements of our customers and, additionally, of course, we need to expand our presence, both in the U.S. as well as in other parts of the world.

    Shimel: Let me talk to you about that a sec, Rani. So, I’m gonna assume U.S. probably represents at least 50 percent of your market, is that about right?

    Osnat: That’s correct, yeah. [Cross talk]

    Shimel: And probably Ameya the lion’s share of the rest.

    Osnat: At the moment, yes, but Asia is also growing, you know, there’s—

    Shimel: I also wanted to ask—what about AP?

    Osnat: Yeah, so Asia Pacific is growing as well. There are a lot of container users in places like Australia, China, Japan, and so forth. And so, this is—these are obviously big economies, there are big companies there. They’re as advanced in terms of cloud adoption as the U.S. in some cases. So, we need to be there.

    Shimel: Absolutely. Well, how do you—so, I was actually out at RSA APJ this summer, and it was in Singapore. And, you know, I had a chance—I actually put on a DevSecOps event there with RSA. So, I had a chance to talk to many of the RSA attendees, some of the vendors and stuff.

    I mean, what’s interesting there is, your infrastructure, you know, even in Europe, AWS is an 8,000-pound gorilla, right?

    Osnat: Correct.

    Shimel: Where do you—we don’t see that in Asia Pac. AWS is still a player, obviously, but there are other solutions there.

    Osnat: Mm-hmm. Yeah, that—

    Shimel: Go ahead. How does that affect you guys, or how do you deal with it?

    Osnat: Well, it affects us partially because mostly, you know, we’re pretty much cloud agnostic, right? We run on all the major clouds. It’s not a major effort for us to run on additional clouds. You know, even today, we support Amazon and Azure, Google, IBM Bluemix. And so, it’s relatively easy for us to support additional clouds, and it’s not a—that’s not the stumbling block, in most cases, right? It’s more like things like esoteric OS’s or weird configurations that we encounter sometimes. But, in most cases, that would not be an issue. Not to mention that a lot of companies are also running private clouds, using VMware or other types of virtualization infrastructure. So, that is really not a stumbling block for us, at all.

    Shimel: Good, good. Interesting. Rani, as I said before, we’re way over time, I need to wrap this up. But, first of all, congratulations on the raise. I’m sure Aqua has 25,000,000 good uses for this money as well, and we’ll see more coming down the pipeline in terms of both functionality products as well as reach around the world. You know, always good to have you on, you have a great handle on where the container market is and of course where the container security market is.

    So, thanks for being our guest today. We’ll have you on again soon.

    Osnat: Thank you.

    Shimel: Thank you. This is Alan Shimel for DevOps and Security Boulevard Chats. Thanks for listening. We’ll hope to see you soon on another chat. Bye bye, everyone.

    — Alan Shimel

  • IBM Adds Cloud Foundry PaaS to Cloud Private

    IBM Adds Cloud Foundry PaaS to Cloud Private

    As IT organizations are being asked to provision and support an ever-growing number of platforms, they increasingly require an approach that abstracts away as much of that complexity as possible. With that goal in mind, IBM created IBM Cloud Private, an on-premises platform that automates the deployment of a private cloud based on Kubernetes container orchestration software. This week, IBM announced it is extending the reach of IBM Cloud Private to include support for the open-source Cloud Foundry platform-as-a-service (PaaS) environment.

    IBM Cloud Private is designed to be deployed on top of virtual or physical servers, including instances of hyperconverged infrastructure based on software from Nutanix. Michael Elder, an IBM distinguished engineer for IBM Cloud Private, says IBM has developed tools for automating the provisioning of not only underlying infrastructure, but also containerized and legacy versions of IBM middleware such as IBM DB2 databases, the Open Liberty Edition of WebSphere application server and IBM Microservice Builder. In addition, Elder says IBM Cloud Private can be employed to deploy a variety of open-source databases, including MongoDB and PostgreSQL.

    Also available for an additional fee with IBM Cloud Private are a plethora of DevOps tools including APM, Netcool, UrbanCode, Cloud Brokerage, Jenkins, Prometheus, Grafana and ElasticSearch. Regardless of the platform employed, IT organizations should be able to apply a consistent set of DevOps processes to manage either Kubernetes or Cloud Foundry, Elder says.

    IBM is also addressing security issues by including Security Vulnerability Advisor to scan containers and an ability to encrypt all data in flight.

    Elder says many IT organizations will deploy 12-factor applications on a PaaS environment alongside containerized applications running on Kubernetes. IBM Cloud Private is designed to provide a common management framework for managing both environments. However, IBM is not extending that management framework to the IBM public cloud. Elder says the company determined that attempting to create a common management framework for both would result in too much complexity, especially for administrators of public cloud services that require a much more streamlined user interface experience.

    Most IT organizations could, of course, craft their own private cloud. IBM Cloud Private simplifies that process by providing all the pieces required under a common management framework. Rather than spending months putting those elements together, IBM is making a case for an integrated platform that enables IT organizations to concentrate more of their efforts on deploying applications instead of managing infrastructure.

    The debate occurring across the IT industry now is to what degree will container-as-a-service (CaaS) environments based on Kubernetes supplant traditional PaaS environments. IBM, as a major supporter of both Kubernetes and Cloud Foundry, is clearly betting there will be room for both. The Cloud Foundry Foundation recently furthered that goal by adding support for a Kubernetes runtime.

    Thus far, however, the complexity of standing up a PaaS environment has limited the adoption of Cloud Foundry to Fortune 1000-class IT organizations or cloud service providers. Meanwhile, CaaS environments based on Kubernetes increasingly are being stood up by developers and then handed over to IT operations to manage. Given that disparity in deployment models, it may not be too long before the number of CaaS environments simply overwhelm the number of instances of traditional PaaS environments.

    — Mike Vizard

  • With Distelli Technology, Puppet Expands DevOps Portfolio

    With Distelli Technology, Puppet Expands DevOps Portfolio

    At its PuppetConf 2017 conference, Puppet made it clear its ambitions now extend well beyond its namesake IT automation framework for IT infrastructure. On the heels of acquiring Distelli in September, the company announced it is adding several products to its portfolio based on technologies developed by Distelli.

    The new offerings include Puppet Pipelines for Apps, to automate commits; Puppet Pipelines for Containers, to automate the building of Build Docker Images from a source repository and then deploying them on a Kubernetes cluster; and Puppet Container Registry, to host Docker images and unify views of them regardless of whether the repositories are local or remote.

    At the same time, the Blueshift platform developed to automate deployments of container platforms such as Kubernetes, Docker Swam and Mesos is also being enhanced. The Kubernetes module now installs the container cluster in a more secure way that is also highly available. The Docker module adds support for Puppet Code Manager, Docker Swarm mode and Docker Secrets. A Kream tool makes it easier to deploy Kubernetes and Helm, a package manager for Kubernetes, at the same time. Helm also now can manage applications deployed on Kubernetes.

    In addition, the company announced Puppet Discovery, a tool that makes it simpler to identify infrastructure distributed across a hybrid computing environment, and Puppet Tasks, which employs new open-source agentless software dubbed Puppet Bolt to automate entry-level IT tasks. Bolt is capable of running existing scripts written in any framework and executing them on any platform that Puppet supports.

    The company is also adding a Task Manager to Puppet Enterprise that makes it easier to manage ad hoc tasks and executing them across hundreds of Puppet nodes. The latest release of Puppet Enterprise includes tools for inspecting packages deployed on and a tool to simplify configurations of those nodes.

    Puppet has also expanded its alliance with Splunk to tighten integration between the two IT operations’ platforms, and formed new alliances with Baracuda Networks, CloudPassage, Conjur/CyberArk, Cumulus Networks, Electric Cloud, F5, Intelliment Security, Onyx Point, Praecipio Consulting and Sensu. In addition, the Puppet module for the Microsoft Azure cloud has been updated to provide access to more disk storage, expanded networking support and support for Azure tags.

    Tim Zonca, vice president of marketing and business development, says with these products Puppet should no longer be considered a one-product company. It is now committed to developing a full range of DevOps management capabilities. That’s significant, notes Zonca, because today there is too much tension between IT operations teams and developers caused by silos of automation across various DevOps processes. As part of that effort, the company is also committing to start to synchronize the release cycles of the various elements of its portfolio.

    As DevOps continues to mature, the line between how infrastructure, applications and security are managed continues to blur. Many IT organizations prefer to acquire a set of DevOps tools from one vendor because it simplifies purchasing and support. Over time, those vendors combine those tools into an integrated suite that aims to unify the management of infrastructures, applications and security. Most vendors today are a long way from unifying those functions, but a wave of consolidation across the DevOps sector suggests the race is on to provide a unified DevOp stack capable of being employed across multiple platforms.

    The percentage of IT organizations that make extensive use of IT automation frameworks such as Puppet is relatively small. Much of the resistance to IT automation frameworks can be attributed now to simple inertia. But as the size and scope of IT environments exceed the capabilities of an internal IT team to manage manually, it’s now only a matter of time before reliance on IT automation increases.

    Puppet and other vendors also have infused their platforms with machine learning algorithms to expand the scope of what can be automated within an IT environment. In general, Zonca says reliance on those capabilities tends to increase in time once the DevOps teams gains confidence in the algorithms’ abilities to make the right decision. Until such time, Zonca says most IT professionals employ those algorithms to either present them with a series of suggested options based on the most recent events that have occurred. Given the nearly infinite number of possibilities that can be inferred from those events, most DevOps teams already are going to need all the machine learning algorithm help they can get.

    — Mike Vizard