devopsy.kinsta.cloud

Tag: cloud infrastructure

  • IBM Extends Cloud Reach to Include Integration

    IBM Extends Cloud Reach to Include Integration

    At the IBM Think 2019 conference this week, IBM unfurled an IBM Cloud Integration Platform that pulls together a range of tools in a single development platform that the company promises will reduce the amount of time it takes to deploy applications by making it easier to reuse integration code.

    Hillery Hunter, vice president and CTO for IBM Cloud Infrastructure, said by bringing all of its primary integration tools into a single cloud platform, IBM is effectively making an integration platform-as-a-service (iPaaS) environment available for the first time.

    IBM this week also formally rolled out IBM Services for Multicloud Management, a portal through which multiple clouds can be managed using software-as-a-service (SaaS) applications developed by ServiceNow, along with a set of IBM Services for Cloud Strategy and Design through which IBM will advise clients on how to architect the right holistic cloud strategy. The premise of both those services is that organizations soon will be rightsizing workloads to run on whatever cloud or on-premises IT platform that best suits them. The portal developed with ServiceNow provides access to dashboards and analytics designed to enable IT organizations to analyze cloud spend and manage workloads deployed on any platform, including Amazon Web Services (AWS) and Microsoft Azure.

    IBM is also extending the cloud services it provides to include the IBM Cloud Hyper Protect Crypto Service, which makes use of IBM LinuxONE mainframes to provide encryption key management built on the only FIPS 140-2 level 4-based technology.

    Hunter said IBM’s approach assumes organizations have already bought into best DevOps practices and API management to provide the means through which multiple clouds will be managed. The challenge many of those organizations are now wrestling with is implementing processes that determine where a workload not only should be developed and deployed but also moved as its characteristics evolve. To provide that analytics, IBM is employing machine learning algorithms running on distributed instances of Kubernetes to continuously track changes and updates to cloud platforms, said Hunter.

    IBM previously outlined a strategy under which it is trying to meld DevOps and ITIL-based processes to make it easier to manage workloads running on any cloud or on-premises IT environment. While the growth of cloud computing continues at an exponential rate, IBM executives this week took pains to remind conference attendees that 80 percent of enterprise-class workloads still run in on on-premises IT environment. In fact, IBM’s rationalization for spending $34 billion to acquire Red Hat is based on that fact. However, while many workloads will continue to run on-premises, IBM is clearly making a case for centralizing the management of all those platforms on IBM Cloud.

    It most likely will take the better part of the next decade to determine where different types of applications may wind up running. Predictions concerning the percentage of application workloads that will run in the cloud continues to be one of the most hotly debated topics in the IT industry. Whatever the outcome, however, it’s 100 percent certain more than one cloud platform will be involved.

    — Mike Vizard

  • Time to Rethink Infrastructure Operations in Enterprises

    Time to Rethink Infrastructure Operations in Enterprises

    “Business is technology and technology is business” seems to be the new mantra as the rules of corporate strategy are being rewritten across industries. According to IDC’s survey in 2017, “Two-thirds of global CEOs will have digital transformation as part of their corporate strategy.”  That’s CEOs—not CIOs—who will have digital transformation as part of their corporate and, not IT, strategy.

    time for change

    While digital transformation is not a new phenomenon, making digitization core to the corporate strategy is a fundamental shift for technology teams. Delivery units, or “change the enterprise” teams, have warmed up to new ways of working over the last few years and are already on the learning journey. Most enterprises today have digital or agile transformation initiatives that tend to focus on the “change” aspect significantly. However, the less glamorous “run the enterprise” dimension tends to be forgotten or side-lined in these initiatives.

    The rise of DevOps was meant to bridge the gap between “change” and “run.” However, many DevOps transformation initiatives seem to be taking the same old path of least resistance that agile transformations have historically adopted: by focusing on the “change” and delivery teams.

    As a consequence, the infrastructure and operations teams—or, “run the enterprise” units—are now waking up to the new reality and have far less time to adapt than their “change” counterparts. The big question really is, What does it mean to infrastructure and operations teams when the CEO is now embracing digital transformation?

    This means that the technology infrastructure required to support business strategy requires a combination of the usual consistency and quality that infrastructure and operations have historically focused on—but only with greater speed, innovation, flexibility and customer intimacy. For the first time, business is looking at infrastructure as equal partners on this journey, not as a subservient IT function.

    What Caused This Shift in Thinking?

    Since 2001, there have been four game-changers in technology that have caused this shift in thinking: the Agile Manifesto of 2001, adoption of Cloud by enterprises, rise of startups and the DevOps movement. The world of technology as we know has been going through a tectonic shift as a consequence of these overlapping waves of change.

    Agile and DevOps

    Version One’s 11th “State of Agile” report highlights that 71 percent of organizations have current or planned DevOps initiatives in 2018. While Agile ways focus on effective team structures, value focused mindset and greater business alignment, DevOps has taken the principles to the logical next steps of delivering value by focusing on flow, amplified feedback loops and building a culture of learning and innovation. In addition, full stack automation covering infrastructure, application delivery and release orchestration has really catapulted DevOps into the top initiatives in organizations. In terms of architecture, new constructs such as evolving design, microservices, containers and serverless computing are all redefining technology infrastructure. The rise of these new ways of working is only piling immense pressure on traditional infrastructure organizations to reform and rethink every aspect of their operating model and challenge processes built on a foundation of perceived stability.

    The Startup Way

    Enterprises increasingly are being influenced by the ways of startups and how they are driving rapid innovation. There is a cross-fertilization of people moving to enterprises who are challenging the thinking in these enterprises, especially infrastructure area. Teams are now embracing once considered absolutely alien, if not impossible, concepts such as chaos engineering and anti-fragility.

    Cloud

    The recent RightScale “State of Cloud” report reveals that 97 percent of enterprises are using cloud in 2017. However, only a small share of their workload has actually been moved to cloud, indicating the potential for cloud in the enterprise context. This indicates that enterprises are past the quick wins such as digital front-ends and will now struggle with the difficult areas of their applications—the bulk of the enterprise apps where the traditional infrastructure constraints and mindset rules. Enterprises can tackle this by truly embracing change, thinking big but starting small with experiments and continuous refinement of the every single dimension of the way infrastructure teams operate.

    “Nothing is permanent but change.” The wise and timeless words of Confucius ring true!

    — Aditya Vadaganadam

  • 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.

  • 5 C’s That Changed the Future – Webinar Series CI, CD, Containers, Cloud & Culture

    5 C’s That Changed the Future – Webinar Series
    CI, CD, Containers, Cloud & Culture

    Join us for case studies of innovation and success with continuous integration (CI), continuous delivery (CD), containers, cloud (infrastructure & migration), and culture (the DevOps kind).

    If you’re on the same mission – to create sustainable systems that empower your business to deliver innovation faster and predictably – then you’ll gain incredible insights from this series. We’ll share the journeys of some very cool companies, joined by a few of the experts who are making it happen.

    Why 5 C’s?

    The consistent theme in these successes is DevOps – culture, process and technology. And when we looked at the results that had the most notable impact on the business, they related to implementations of some or all of the 5 C’s. Results such as:

    • 10x faster new product delivery.
    • Internal & client confidence in iterative development, driven by innovation in quality & feedback.
    • Modernized traditional apps by adding self-healing, auto-scaling, and rolling deployment capabilities.
    • Blameless culture, enabled by feedback and consistency across dev, test & prod environments.
    • Security integrated across the stack and not simply a checkbox.

    The series:

    • Tuesday, Oct. 3 – CI/CD, Containers & Culture
    • Tuesday, Dec. 5 – Cloud Infrastructure & Culture
    • Tuesday, May. 15 – Cloud Migration & Containers

    View On-Demand Webinar (Oct. 3):
    Faster Innovation with Confidence – How CI/CD & Containers Help Arrayent Go Faster

    View On-Demand Webinar (Dec. 5):
    Scaling Cloud Infrastructure for Millions of Devices

    View On-Demand Webinar (May 15)
    Cloud Migration: Solving for Growth with Containers & DevOps on AWS

  • Case Study: Stytch Before, After DevOps Culture, Tools

    Case Study: Stytch Before, After DevOps Culture, Tools

    Cloud analytics provider Stytch leverages its cloud-based analytics for customers who want to centralize, fuse and model their data. “Our mission is to make it easier and faster for business users to get insights and make decisions,” said Taylor Frost, cloud operations engineer at Stytch.

    Before the company implemented a DevOps approach, its primary software platform and some services were large monoliths maintained by disconnected teams. Stytch tested new features in isolated Jenkins jobs and performed quality testing and product releases manually in siloed realms that were out of sight and out of mind, Frost said.

    Stytch’s Dev, Ops and QA were walled  from each other, isolating the knowledge base of activities in any one group from members of the other two groups. Stytch teams did not share this information, and sister teams could not benefit from the insights this knowledge held.

    What’s more, developers did not have transparency into the products and tools that manipulated the cloud-based infrastructure or the build pipelines. “This fostered an attitude of ‘it’s an (Ops/Dev/QA) problem’ and discouraged a sense of ownership of or responsibility for success, which led to an increasingly lengthy feedback cycle and slower, less frequent builds,” Frost noted.

    Stytch lacked the orchestration and the down-in-the-weeds level of control it needed to enable real-time changes to labyrinthine back-end technologies without repercussions that could cause the customer base to suffer, and to speed and simplify deployment, she said. Standards such as Terraform or CloudFormation did not provide the fine-grained control of deployment that Stytch needed.

    The company’s Ops was in charge of Python software libraries, but other groups including Dev and QA needed access. Stytch also has a performance team that the company was eager to include in Python library development.

    Stytch After DevOps

    Stytch is using DevOps to unite teams and divide the various software monoliths into microservices for continuous integration (CI) and continuous delivery. The company has already fed its core software platform through the new build pipeline a number of times, and continues to create even more automated and efficient deployment processes.

    As it works to create homegrown Python orchestration libraries, Stytch is establishing a stronger grip on deployment. All teams connected to the pipeline including Dev, QA and Performance are actively expanding these libraries.

    Stytch increasingly intermarries its Dev, QA, Ops and Performance teams and enables and rewards collaboration across the stretch of the DevOps pipeline. “Our goal is transparent, scripted change integration, from check-in to testing and deployment. We empower our developers to take responsibility for their work, from check-in to production deployment,” Frost said.

    Stytch uses frequent meetings of a continuous delivery committee with members from all four groups to update the status of the pipeline. The company is swapping out Jenkins for Travis CI for builds and tests, making Dev more hands-on and able to gauge its work from start to finish.

    “Developers are iterating on their pipelines in the same way that they iterate on their projects,” Frost said. Stytch is able to find and fix problematic code earlier in the pipeline while accelerating development cycles. Customers are pleased with the faster rate of innovation on the software platform they use.

    New Infrastructure, Training = More Results

    Stytch has made cross-pollination of expertise common for pipeline teams. “We have an annual training allowance and our engineer-led ‘Ministry of Propaganda” holds regular afternoon sessions to introduce new technology and practices,” Frost said.

    As CI and continuous delivery processes grow, absorb and automate manual steps, related activities across the pipeline become more translucent for everyone. Both the Travis CI platform and the use only of scripted product releases and scripted tests for performance are increasing that transparency.

    The metamorphosis that has spread throughout the teams with direct access to the DevOps pipeline now extends to the rest of the company, as needed, such as with marketing. Frost provided an example:

    “Our marketing team was struggling to make good progress with regular releases of our WordPress-based website. Our engineers were fielding regular requests for basic tasks—starting and stopping servers, updating configuration files and retrieving logs,” she said. “We brought our engineers and marketing together on this. The result was a simple command-line tool that enabled our nontechnical marketing staff to perform complex actions on their own, including promoting their changes to the production environment.”

  • The Maturing OpenStack Cloud: Just Do it

    The Maturing OpenStack Cloud: Just Do it

    We’ve been thinking about the maturing cloud a lot lately. In fact, we’re participating in a panel discussion on the topic at the upcoming OpenStack East in August in New York. As we’ve spoken with OpenStack users and vendors throughout the world we’re hearing a common theme about the maturation of OpenStack clouds—the results seldom look like what was originally planned. Disruptive technologies, changes in personnel, the evolution of business strategies … these are all unplanned events that can change what the mature cloud eventually will look like. The challenge for today’s DevOps teams is to how to maximize the opportunities for success, despite the likelihood of unanticipated changes. After all, as many DevOps folks know, between the design of an application or system and the completion of that project, they often are faced with a change in the initial business requirements of the project.

    Lao Tzu famously said, “The journey of a thousand miles begins with one step.” While that is true, we’d add that the journey will be much smoother if that one beginning step relies on careful consideration of the best shoes for the journey: shoes that are comfortable, durable and multi-purpose. Shoes that see you through any type of weather. The right shoes won’t necessarily get you to the right destination, but they certainly will make your journey easier and better ensure you complete your journey—even if you end up somewhere other than where you thought you would.

    So what do shoes have to do with the OpenStack cloud? We liken choosing the right shoes to making the right architectural decisions at the beginning of your OpenStack journey. One of the most important architectural decisions DevOps can make early in the development of the OpenStack cloud is to include a comprehensive data protection strategy, accompanied by the appropriate tools to facilitate that. There are three primary reasons to include data protection from the start:

    • It’s a “given” for VMWare and other enterprise applications for a reason. One might argue there’s no need for data protection, since everything lives in the cloud. But we all know files, applications and systems can fail for no apparent reason. It’s much easier to recover from a failure if you have a data protection strategy in place, rather than having to suddenly (and often quickly) re-create the lost resources.
    • It will make it easier to manage OpenStack and cloud resources. As your OpenStack cloud grows, you may need to move workloads to different availability zones or data centers. While you may have a general idea of your resources needs at the beginning of the DevOps process, chances are things will change along the way.
    • It makes for a smoother upgrade process. Chances are that you are not rolling out your OpenStack cloud with the exact OpenStack version you started with. For example, one of our customers started on Kilo and now is migrating to Mitaka for its rollout. Their migration is much easier because the customer knows everything is backed up, available to use and restored in its new, upgraded environment.

    Sure, the OpenStack and the cloud paradigm is enabling DevOps and business users to upend many “traditional” approaches to IT. But that doesn’t mean you should toss out every strategy that’s considered “traditional.” After all, if you were buying your shoes for your thousand-mile journey, would you only buy one pair? Or make sure you have a spare just in case?