Category: DevOps in the Cloud

  • Cloud Computing and the Concept of DevFinOps

    Cloud Computing and the Concept of DevFinOps

    The formation of DevOps brought together two distinct worlds, causing a shift in IT culture that can only be made better (and more cost-effective) by the integration of financial strategy. Enter DevFinOps. I say this only partially in jest. As long as the public cloud remains a utility, everyone should be responsible for controlling the cost of their cloud use, meaning “continuous cost control” should be integrated into the processes of continuous integration and delivery.

    Companies should at least start thinking of financial management as an element in the DevOps process. Time and time again, I see DevOps teams overspend and face major organizational challenges when inevitably the finance team (or the CTO) starts enforcing a stricter budget. Cost control becomes a project, derailing forward development motion by rerouting valuable resources toward implementing spend management processes.

    It doesn’t have to be this way. As financial resources are finite, they should be an integrated element from the very beginning when possible. There are a number of ways that finance can be integrated into DevOps, but one near and dear to my heart is with automated cloud cost control. A mental disconnect between cloud resources and their costs causes strain on budgets and top-down pressure to get spending under control.

    Changing the Mindset: Cloud is a Utility

    The reason for this disconnect is that as development and operations have moved to the cloud, the way we assess costs has changed profoundly in the same way that infrastructure has changed. A move to the cloud is a move to pay-as-you-go compute resources.

    This is due to the change in pricing structure and mindset that happened with the shift from traditional infrastructure to public cloud. As one of my customers put it:

    “It’s been a challenge educating our team on the cloud model. They’re learning that there’s a direct monetary impact for every hour that an idle instance is running. The world of physical servers was all CapEx-driven, requiring big up-front costs, and ending in systems running full-time. Now the model is OpEx, and getting our people to see the benefits of the new cost-per-hour model has been challenging but rewarding.”

    In a world where IT costs already tend to exceed budgets, there’s an added struggle to calculating long-term cost estimates for applications that are developed, built and run on a utility. But wasn’t the public cloud supposed to be more cost-effective? Yes, but only if every team and individual is aware of their usage, accountable for it and empowered with tools that will give them insight and control over what they use. The public cloud needs to be thought of like any other utility.

    Take your monthly electric bill, for example. If everyone in the office left the lights on 24 hours a day and 7 days a week, those costs would add up rather quickly. Meanwhile, you’d be wasting money on all those nights and weekends that your beautifully lit office is completely empty. But that doesn’t happen because in most cases, people understand that lights cost money, so people have automated this process in the office by using sensors either based on motion (usage) or time-based schedules. Now apply that same thinking to the cloud and it’s easy to see why cost-effectiveness goes down the drain when individuals and teams aren’t aware or accountable for the resources they’re using.

    Financial decisions regarding IT infrastructure fall into the category of IT asset management (ITAM), an area that merges the financial, contractual and inventory components of an IT project to support lifecycle management and strategic decision-making. That brings us back to DevFinOps: an expansion of ITAM, fixing financial cost and value of IT assets directly into IT infrastructure, updating calculations in real time and simplifying the budgeting process.

    Why This is Important Now That You’re on Cloud

    DevFinOps proposes that a more effective way to estimate costs is by breaking them down into smaller estimates over time as parts of the work get completed, integrating financial planning directly into IT and cloud development operations. To do this, the DevOps team needs visibility into how and when resources are being used and an understanding on opportunities for saving.

    As I have noted, the public cloud is a utility—you pay for what you use. And with that in mind, the easiest way to waste money is by leaving instances or VMs running 24 hours a day and 7 days a week. The easiest way to save money is just as simple: turn them off when they’re idle.

    — Jay Chapel

  • Morpheus Data Extends DevOps Reach

    Morpheus Data Extends DevOps Reach

    Morpheus Data signaled it will pursue a more open strategy when it comes to enabling DevOps teams to manage multiple cloud platforms.

    Brad Parks, vice president of marketing and business development for Morpheus Data, said updates to the company’s namesake platform will make it possible for DevOps teams to swap in third-party modules and components even when Morpheus has already provided that equivalent functionality in the platform. This more open approach is being driven by a recognition that in many cases DevOps teams are being required to implement a specific corporate standard, Parks said.

    The latest edition of the Morpheus cloud management platform adds support for Kubernetes container orchestration software, Terraform configuration management software developed by HashiCorp and Microsoft Azure Resource Manager. Morpheus already has its own JSON/YAML scripting framework. But it’s clear more declarative approaches to managing cloud resources using, for example, Kubernetes or Terraform are starting to gain traction, Parks noted.

    At the same time, Morpheus is adding connectors to cloud services from Oracle and T-Systems.

    At its core, the Morpheus cloud management platform enables DevOps teams to consolidate analytics, reporting, governance, monitoring, logging and data protection within a single platform. Most organizations today either already are or expect to soon employ multiple clouds. Each of those clouds will be running different classes of workloads as IT organizations move to keep their cloud service provider options open. At the same time, Morpheus Data is betting that, rather than mastering separate management consoles for each cloud, organizations will move to centralize the management of multiple clouds as much as possible, Parks said.

    Parks noted Morpheus Data is also starting to see DevOps teams hooking up their preferred continuous integration/continuous deployment (CI/CD) platform to the Morpheus cloud platform. That approach provides them with a platform to manage applications starting the minute a CI/CD pipeline finishes pushing them into production, he said.

    CI/CD platforms and other DevOps tools are great when it comes to building and deploying applications, but currently a gap exists between how those applications are built and deployed versus managed when deployed in a production environment. Morpheus is designed to provide an open flexible approach to closing that gap, Parks said.

    Interest in various approaches to automating the management of IT is clearly on the rise. Most organizations simply don’t have enough IT staff to manage large numbers of applications being deployed at scale. In fact, Parks said Morpheus Data is seeing a marked rise in the number of managed service providers focused on DevOps and cloud management services.

    Regardless of how the integration of DevOps and cloud management is achieved, it’s clear IT processes are being transformed. The day when silos within IT organizations implemented various levels of IT automation based on various capabilities of platforms is starting to give way to a more comprehensive approach. The real challenge now is figuring out how to achieve that goal with the least amount of reasonable disruption to the culture of the IT organization as possible.

    — Mike Vizard

  • Reliance on Cloud Foundry PaaS Increases

    Reliance on Cloud Foundry PaaS Increases

    A survey of 383 IT professionals published April 18 suggests the open source Cloud Foundry platform-as-a-service (PaaS) environment is gaining traction across the enterprise.

    The survey conducted by the Cloud Foundry Foundation (CFF) finds one-third of companies now have at least 100 developers using Cloud Foundry. The number of companies with more than 50 developers using Cloud Foundry rose from 20 percent to 47 percent in the last year. More than half the respondents (53 percent) report they have been using Cloud Foundry for less than two years.

    Companies with more than 50 applications on Cloud Foundry rose from 24 percent to 40 percent in just over six months and nearly a third (30 percent) of respondents describe their Cloud Foundry usage as broad.

    More than a third of Cloud Foundry users report they now save a few months or more per application development cycle, and 10 percent report saving more than six months. In addition, nearly a quarter report saving $500,000 per application development cycle, with 17 percent saying they have saved more than $1 million.

    The survey also finds there has been a sharp rise in interest in containers. A total of 13 percent of respondents already are using both the Cloud Foundry Application Runtime (CFAR) and the Cloud Foundry Container Runtime (CFCR), which is based on an instance of Kubernetes. Another 45 percent are evaluating CFCR.

    CFF CTO Chip Childers said he expects the Cloud Foundry PaaS and Kubernetes to be employed side by side for years to come. The CFF will continue to develop technologies that unify the management of Cloud Foundry and Kubernetes before there is an inevitable convergence of the two platforms, he said, adding that for now, a PaaS and container-as-a-service (CaaS) environment are serving different classes of applications. In the case of Cloud Foundry, that historically has been complex 12-factor applications. But Childers noted that the types of applications being deployed on Cloud Foundry is also expanding.

    Overall, Cloud Foundry reports more than 3,200 contributors participating in the community, with more than 60,000 commits in the last 12 months alone. According to Gartner, the total market value Cloud Foundry is approximately $3.1 billion.

    As application development continues to evolve, it is clear many organizations are embracing multiple platforms. Different business units within organizations want to be able to develop applications in the cloud or on-premises as needed. Ninety percent of ten Cloud Foundry users surveyed cited cross-platform flexibility as important capability, with 67 percent calling it “very important.” One of the core value propositions of Cloud Foundry is that it provides a highly portable platform backed by a consortium that includes IBM, Pivotal, SAP, SUSE and, now, Alibaba.

    In general, DevOps teams are embracing PaaS and CaaS environments to take advantage of higher levels of abstraction that don’t require them to manage the underlying IT infrastructure. The theory is that the more automated the environment becomes, the more resources there are to allocate to developing applications versus managing the platform.

    The trade-off is that each PaaS and CaaS environment is usually highly opinionated in terms of how the application development process should be managed. Because of that issue, many organizations still prefer to build their own platforms from the ground up. But as PaaS and CaaS platforms continue to mature, it’s likely many more organizations may decide there isn’t enough differentiated value to be gained by building a platform themselves.

    — Mike Vizard

  • VMware Extends vSphere Hybrid Cloud Reach

    VMware Extends vSphere Hybrid Cloud Reach

    VMware this week extended its campaign to automate IT environments based on its hypervisors by adding a link capability that enables the VMware vCenter platform to manage instances of VMware vSphere running on-premises and in public clouds such as Amazon Web Services (AWS) and IBM Cloud from the same console.

    Mike Adams, senior director of cloud platform product marketing for VMware, said the linking capability added to VMware vSphere will enable DevOps teams to deploy the VMware hypervisor anywhere without having to invest in a separate management framework for each environment.

    At the same time, VMware is also updating VMware vSAN storage software that, among other capabilities, adds a self-healing feature designed to minimize disruptions in the event of underlying hardware failure.

    Version 6.7 of VMware vSphere and VMware vSAN also now support enhanced client software based on an HTML5 interface that can manage VMware NSX network virtualization software, vSAN and vSphere along with additional third-party products.

    Other new features in VMware vSphere include ESXi Single Reboot, which reduces patch and upgrade times by halving the number of reboots required to one, and vSphere Quick Boot, which will skip hardware initialization steps to gain further re-start efficiencies.

    VMware is also adding support for persistent memory to speed vSphere performance and adding support for graphics processor units (GPUs).

    There’s also now support for both Trusted Platform Module (TPM) 2.0 Support and Virtual TPM 2.0, which serves to protect virtual machines and hosts from being tampered or compromised by the loading of unauthorized components or allowing a guest operating system running on the hypervisor to circumvent existing security controls.

    Finally, VMware is making available an instance of VMware vCenter management software running on a dedicated appliance.

    Adams said VMware today has 500,000 customers running VMware vSphere, compared to 10,000 that have elected to also run VMware vSAN storage software. The goal for the company is to enable more IT organizations to embrace hyperconverged infrastructure by moving storage software on to the same server where VMware vSphere runs. That approach dramatically reduces the total cost of operations for most organizations, he said.

    As VMware makes an arguably belated push into the public cloud, the unit of Dell Technologies is counting on a massive installed base of on-premises customers to move and expand their existing investments in VMware vSphere on public clouds. While there’s no doubt that approach will appeal to significant part of the VMware installed base, many customers have already invested in the hypervisor platforms used by AWS, IBM and Microsoft.

    When it comes to lifting and shifting an existing legacy applications into the public cloud, VMware clearly has the inside track. But when it comes to development of greenfield cloud-native applications, VMware vSphere is not often the first choice of application developers, many of which view VMware vSphere as part of an inflexible on-premises legacy IT environment that they deliberately left behind.

    To its credit, however, VMware is making significant strides in embracing advanced automation technologies that one day soon might put those developer concerns to rest once and for all.

    — Mike Vizard

  • DevOps Chat: The CEO’s View with Derek Langone, XebiaLabs

    DevOps Chat: The CEO’s View with Derek Langone, XebiaLabs

    This DevOps Chat features “the CEO’s view” as seen by XebiaLabs CEO, Derek Langone. Derek is one of my personal favorite CEOs in the DevOps space because he is very articulate, to the point and sharp. I think all of these characteristics come through in this DevOps Chat. As CEO of XebiaLabs, Derek is leading one of the leading companies helping transformations in enterprise DevOps. In this chat, Derek talks about with us about cloud and cloud migration.

    As usual, the streaming media of our conversation is below. The transcript of our conversation follows below that.

     Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 122032″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Derek Langone
    Derek Langone has been the Chief Executive Officer of XebiaLabs, Inc. since April 21, 2015. Mr. Langone served an Executive Vice President of Global Sales at Telerik, Inc. since February 2014. Prior to Telerik, he served as the Chief Executive Officer of 5nine Software where, in less than a year, he significantly increased revenue, lead generation and conversion rates. He served as the Chief Executive Officer, President and Chief Operating Officer of SmartBear Software, Inc. (also known as AutomatedQA Corporation). He served as the President and Chief Operating Officer of SmartBear, Inc. He began his career on Wall Street focused on technology investing. For over 15 years, he has focused on building and scaling Technical Sales Organizations. Prior to SmartBear, he served as Vice President of Sales at Quest Software and IMCEDA Software. He held senior Sales Positions at Vality Technology, (now IBM), Embarcadero and SAP America. He is an Industry Veteran, has more than 15 years of expertise in cultivating enterprise IT and application development adoption. He has been a Director at XebiaLabs, Inc. since April 21, 2015. Mr. Langone holds a Bachelor’s Degree in Business Management from Boston University.[/su_pullquote]
    Alan Shimel: Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps chat.  Happy to be joined today on DevOps chat by Derek Langone, CEO of Xebia Labs.  Hey Derek, how are you

    Derek Langone: Alan, I’m excellent, thanks very much for having me today.

    Shimel: Thank you. Just a heads-up to our audience, I had been working on this for a long time. Derek’s agreed to be sort of a regular guest here on DevOps Chat and we’re looking forward to hearing from him, oh, maybe once a month or so on topics that are of interest to hopefully our whole audience so you know they’ll be around DevOps and related to technologies.

    So, this is the first one we’re doing and we were going to talk today a little bit about cloud and whether you already are a cloud customer or new to the cloud, how can DevOps and related technologies help you.

    But before we do, Derek, in case there’s anyone out there who maybe is not familiar with Xebia Labs, you want to give them a real quick kind of pitch on Xebia Labs and what you guys are doing?

    Langone: Sure, here’s the 30-second commercial. So, Xebia Labs is entirely focused on enterprise DevOps. We provide a software platform for large enterprises that encompasses three primary components, released orchestration so basically create your pipelines in our technology that are templated, repeatable, standardized, use our automated deployment engine which is a model-based agentless engine.

    And then lastly, we have a machine-learning and AI-oriented reporting engine that collects all the data associated with your journey from development to production. It allows you to report on that for things like compliance purposes, regulatory purposes, security, and just a good old-fashioned scorecard – am I going faster? Is my quality up? Are my customers happier?

    Shimel: Couldn’t have asked for more than that in 30 seconds, Derek, thanks. So, here’s the deal, we are approaching I think this year a threshold in cloud adoption where it’s something like 50 percent of enterprises will have significant infrastructure in the cloud, not just a toe in the water or an R&D project, but significant infrastructure in the cloud.
    And that’s big, right?That means half of all enterprises have a large investment in cloud. But it also means half, don’t, right? And that’s always the flip side of the coin. I want to talk today to both of these audiences but let’s first start with the half that already has, right?

    They’ve invested a lot time, a lot of money, probably a lot software or tools and personnel, but maybe they’re not getting everything they need out of their cloud deployment? How can DevOps help?

    Langone: Well, DevOps by principle is sort of an accelerate opportunity, right? And if you look at a cloud investment, it’s a similar value proposition that you don’t have the requirement to manage this infrastructure, you’ve got less administrative overhead, you’ve just got on-demand, scalable infrastructure. So, that’s all oriented around speed.

    The challenges we see with our customers that are generally large enterprises, the biggest banks, insurance companies, airlines, in the world represent our customer base. They’re moving aggressively to the cloud because it’s just generally less expensive and certainly much less administrative overhead.

    But the consequences, the applications they’re trying to get there are very complex and don’t necessarily lend themselves to moving to the cloud very neatly. And what I mean by that is if you use an example like a large bank might have a money transfer application, core to every business that’s a big financial institution.

    That application lives in many places; the back-end horsepower may be a mainframe, there’s referential databases that do some validation every time there’s a query. You’ve got distributed architecture, maybe a containerized front end that gives you your mobile banking access and things like that.

    Moving all of that to the cloud is not simple, it really requires an incredible amount of orchestration, some very sophisticated deployment functionality. And we see most of our customers when we get engaged, them trying to do that with either the simple tools that come with the cloud platform providers, you know, the out-of-the-box Amazon or Azure tool portfolio.

    Or in most cases, just using the good old- fashioned, using extremely talented valuable developers to write tons of scripts to try to move these components around and shift them to the cloud. Neither of those initiatives are generally successful.

    Shimel: And I think you just hit it, Derek. Those are the two ends of the dumbbell if you will, right? One is to use the vanilla tools that the cloud providers give you and not to bang anyone but AWS is notorious for this, right?

    They give you 60 percent of the functionality at a really low, low price of some of the best __ tools but it comes bundled. Or you go the other way, right, just totally customize the heck out of things, which is not scalable usually, nor repeatable.

    Langone: No, it’s not, that’s the challenge. And just to hit those two ends of the dumb-bell as you said, the tools that come with the cloud providers, I mean, look, they’re sort of minimalistic by nature because it’s not the core business that they’re trying to provide. They’re infrastructure providers, they’re really not deployment technologists, right?

    So they’re gonna give you a little bit to get some basic applications there but anything complex is really gonna fall down. And like you said, the other side of it is, and the more traditional approach, is just using your engineering assets to write a ton of scripts to provision infrastructure, to migrate applications, to request instances.

    You know, it’s just an incredible amount of plumbing code that gets written that is super low-value and basically comes at the expense of much higher value activities that those engineers could be participating in, things like building new features and fixing bugs and just basically delivering more customer value.

    Shimel: And with that approach, Derek, to me it’s always been, well, what happens next month when I have to do this again? I’m gonna rewrite all the scripts, waste all that time? It just doesn’t make sense. But you hit on this with your opening, the reality is that most of these organizations who may already have significant infrastructure in the cloud are not totally in the public cloud certainly.

    They still do have mainframes, they have stuff in the closet, they have stuff in the data center. They’re living in a hybrid world, right, Derek? And so for whatever reason, and I’ve heard this from numerous, they hate the idea of using one tool for their public cloud stuff, one tool for their on-print stuff, one tool for their private cloud. They want one throat to choke, right? They want one tool.

    Langone: Well, I think they want one platform that can kind of account for the migration and IT landscape that they are going through, right?

    Shimel: Yes.

    Derek Langone:And that’s sort of what we’ve tried to build at Xebia Labs. We work with the legacy infrastructure and give you velocity, repeatability, standardization for your mainframe deployments in the exact same way that we will accelerate your journey to containers and leveraging Kubernetes and Docker as well as, you know, getting onto what is generally hybrid cloud infrastructure.

    We definitely see large organizations leveraging things like Amazon but in most cases, they’ve got some combination of a data-center cloud that they’ve got under their own control, as well as the sort of less mission-critical applications or the things that don’t represent the family jewels if you will in true public cloud infrastructure.

    And when I talked to CIOs in these organizations about their aggressive shift to the cloud, they look at me and say, look, we’re moving to the cloud with a lot of new development and some of the less mission-critical applications but the five apps that we run the bank on are gonna be running on mainframes five years from now.

    That’s not changing. We can’t break them up into micro-services and they don’t lend themselves to refactoring. We’re gonna continue to just add, you know, additional workload front ends but for the most part, they’re gonna stay intact. And that just represents I think the reality in enterprises.

    Shimel: And that is dead on the reality. And I just want to make sure we’re talking about tools like Xebia actually give these organizations the ability to use one platform across these multiple infrastructures.

    Langone: Yeah, I mean, look, I don’t want to just plug our platform because there’s others out there, there’s others out there, but at the end of the day, yes, what we’ve tried to do is basically build the technology that can accommodate the mission-critical requirements of a large enterprise. So, not only have we baked in the ability to deploy any technology from any starting point to any destination including public cloud, private cloud, hybrid, containers, you name it, right?

    We’ve also baked in all of the things that enterprises need to account for, like the compliance steps, the security steps, the who did what and when to the software reporting, so that all of these standards are met if you’re migrating to infrastructure that’s off of your own premises.

    None of those business requirements go away. In fact, in most cases, they get a little bit more stringent as the security team start to understand that if you’re gonna move applications outside of the firewall of the organization, then we need to put even more validation steps and security procedures in place.

    And again, if you’re doing this manually with engineers, they need to script for all of that activity and maintain it every time there’s a slight change in the application.

    It just becomes 50 percent of an engineer’s day managing these scripts that were built to move applications around when they could be using that 50 percent of their day to do things that are much, much more interesting for them and much more valuable to the organization.

    Shimel: Sure, I mean, and again, we’re not tooting Xebia’s horn here but you know what, Derek, from a manager-executive point of view maybe listening to this, knowing that there are tools like that that will allow them to go across these different infrastructures, single platform, is important. I mean, that was always one of the big inhibitors.

    Langone: No, you’re absolutely right, and look, what we’re tried to build into our platform is this templated approach. We have a model-based architecture, it’s agentless so you create templates and every single application that you have to move from development to production follows one of maybe three or four templates.

    And we’re talking 3 to 4 templates account for 500 different applications, whereas the alternative is you’re basically hand-scripting 500 different paths to production. So it’s much easier to maintain, it’s centralized, it’s controlled, there’s reporting, there’s visibility, there’s sort of all the things that you need to be able to score your process for migrating applications, whether it be to the cloud, the containers, or just frankly, to an existing data center.

    So, that’s really an important consideration. The other piece to consider, and again, a place where we’ve put a lot focus in our platform is leveraging what you’re doing already. So, we are a part of the process but you’ve got provisioning tools, like Puppet and Chef, you’ve got service ticketing, like Service Now or Gira, Jenkins on the CI side.

    A lot of technologies are required to move applications from one destination to the next, so we integrate with all that infrastructure that’s already running right out of the box, and we basically allow you to pick best-of-breed components so that you’re not locked into one specific vendor. And that’s been a lot of the feedback that we get from our particularly big financial services customers.

    They like the fact that if they want to switch cloud providers on the fly and move from Amazon to Rat Space or from Rat Space to Azure, they can do that with changing one configuration file in our product rather than having to rescript everything from scratch to reach a new destination.

    So, it really comes down to you avoid vendor lock-in, but when you want to make a pivot, that pivot in our technology and our platform takes five minutes versus months of scripting. 

    Shimel: Months, exactly. So, Derek, let’s make our own pivot, let’s talk about the other 50 percent of companies that aren’t moving major infrastructure to the cloud, or big parts of their infrastructure to the cloud. Let’s first of all say should they? Should they feel they’re getting left behind? Is it fatal to their business? What’s your feeling?

    Langone: You know, I think every IT organization makes choices that line up to the business objectives of their firm. I wouldn’t say that the shift to cloud is mandatory. There’s certainly a strong value proposition associated with it. It’s very, very expensive to keep technology infrastructure fresh. That’s always been the issue.

    You could build the data center but then, you know, 18 months later, all the technology in there is sort of out of rev, right? So you’re forced to buy it over and over and over again versus the cloud providers. You’re certainly paying the rental fee and that rental fee can be steep but you’ve always got state-of-the-art infrastructure to work against, and that’s just a very compelling argument.

    The other pieces, the administrative element goes away so there’s less people required to maintain it because it’s getting maintained for you. But the majority of our customers are moving to the cloud but for specific reasons and with specific applications, right? They’re not just wholesale-lifting their entire application portfolio to the cloud because it’s just not practical.

    So in the cases of customers that are still on premise, and that’s still the majority of large enterprises, I am not at all a cloud-denier. People are moving there and moving there aggressively, but when you look at large enterprises, I think your number was 50 percent are using and 50 percent are not.

    My on the ground sort of feeling is it’s less than 50 percent that are aggressively using the cloud for many different reasons, not the least of which are just security concern that still sort of haunt these large organizations. But the fact is anywhere your applications reside, right now DevOps is a good investment.

    Being able to increase the velocity at which you can build technology and deliver value through software to your end users is sort of a fundamental requirement nowadays in order to stay competitive in your own given space.

    So, we help with velocity, like I said earlier, on mainframes distributed technology, legacy systems, building a repeatable standardized release and deployment process with all the reporting that you’d expect to be able to identify where you’ve got areas of friction that can be remedied.

    So, we sort of approach with the same – our approach is the exact same whether it’s a legacy application or a nimble application that’s being written in containers to run in cloud infrastructure.
    The templates are the same, the mechanics of how you release and deploy those applications is the exact same.

    So, the beauty of our platform becomes anybody can use it, it’s understood, it’s centrally managed and it scales infinitely versus writing code which just is difficult and impossible to maintain over time. 

    Shimel: Sure. So, Derek, you brought an interesting point up though and it was one that I wanted to hit on. And that is, look, for those who are just moving to cloud, right, there’s a choice to be made. Do I take my inherited legacy, not so much infrastructure as much as my legacy stack and just port this existing stuff to the cloud?

    Or do I really just bite the bullet in Greenfield, right? Like, my stuff hasn’t been built on containers, maybe it wasn’t even built on hypervisors and virtualizations – who knows? But you know what, if I’m gonna move to the cloud, the heck with it, I might as well containerize and take advantage of micro-services and all of this.

    But my goodness, that’s such a major, you know, throwing out babies with bathwater potential. What’s your advice to companies faced with do I just port my existing architecture, or do I go for broke in more ways than one and adopt the new stuff?

    Langone: Yeah, I’ll tell you, in my experience, and I wouldn’t want to give advice ’cause every company sort of has to line up against their business objectives. But what I will tell you, what we see most often is people threading the needle, right? Basically taking these monolithic applications and starting to build components of those applications in containers on sort of more nimble infrastructure.

    You know, a good example, as I mentioned earlier, a money transfer app, right? That’s a legacy application that’s been running in a big bank for 25 years. The horsepower on the back end that does all the computations is still a couple of IBM mainframes strung together. But you’ve got referential databases that are living in distributed architecture maybe onsite, maybe offsite in the cloud somewhere.

    You’ve got containerized and mobile-centric front ends so you could do your mobile banking, web banking, things like that. So, that application lives in a lot of different places and you can, with some small investment in more nimble development platforms and infrastructure on the front end, really energize and give life to these legacy applications.

    So, there isn’t a need to move the entire thing to the cloud. You can move components of it to the cloud, but again, when you do that, you get the benefit of the faster architecture and the ability to deliver value through your software more frequently for your end users.

    But the consequences, getting those components to the cloud becomes really complex and that’s where our technology really lends a hand, where we understand those complexities, we’ve accounted for them already.

    We do this sort of every day for the biggest banks in the world so you can take advantage of not having to reinvent the wheel and still get the benefit of the velocity that you’re looking for and the flexibility you’re looking for in these applications that need to live on.

    Shimel: You know what, Derek, that was one of the best examples of hybrid cloud that I’ve heard. I think for too many people they think of hybrid cloud, they say, well, this application lives in the cloud, this application lives on my mainframe, this application lives in a data-center, my payroll system is here, my HR system is there, but that’s not really hybrid cloud.

    Hybrid cloud is we have one application that different elements and components of it live in this hybrid world, right?

    Langone: Yes, I think there’s a misunderstanding that you’re either in the cloud or you’re not, right? The fact is, I think, that in most cases, most of our clients, you’ve sort of got one leg in both places.

    Shimel: Yeah, at the same time.

    Langone: You’ve got I’m somewhat in the cloud, and they make decisions relative to where can I get the biggest bang for my buck? Some of this application needs to be in the cloud for a bunch of reasons so let’s do it, and then we’re just not gonna forklift up our mainframe apps and dump them on AWS. It’s a cost-ineffective strategy; we’d have to refactor them like crazy.

    So, yeah, and I don’t think that trend is gonna change, right? There’s certainly a bunch of Greenfield development that’s going on, containerized apps micro-services, just cloud-centric development. And that’s great but that represents generally less than ten percent of the application portfolio in a large organization.

    And that’s the fact is that 90 percent of the apps have been around for five years or longer, and those apps are critical to the business.
    And they, over time, will migrate to the cloud and be refactored and rewritten.

    But it’s just too big of an endeavor for any large company to take a 1000-application portfolio and say, hey, this year we’re going to rewrite all these for the cloud. I mean, I don’t know anybody that’s doing that.

    Shimel: I would hope not. Hey, Derek, I think I told you before we started, time goes really quick here. We’re at maybe 25 minutes now, we were supposed to be 15, so we could probably talk about this all day, but we’ll continue the conversation on our next visit with you.

    But, hey, this was great, Derek Langone, CEO, Xebia Labs. Thanks for being our guest on DevOps Chat today and we hope to have you back real soon here.

    Langone: Thanks, Alan, talk to you soon.

    Shimel: All right, this is Alan Shimel for devopsy.kinsta.cloud, we’ll see you soon on another DevOps Chat.

    — Alan Shimel

  • DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and cloud computing are not mutually exclusive, though their relationship has often been uncertain and confusing from a layman’s perspective. While cloud computing relates to technology and services, DevOps is more about processes and process improvement. However, both DevOps and cloud computing are vital in every organization’s journey toward an effective digital transformation.

    Cloud-centric DevOps Automation

    Cloud computing’s centralized nature enables a standard and centralized platform for DevOps automation. Using a cloud platform resolves issues in centralized software deployment caused by the distributed nature of enterprise systems.

    DevOps objectives including continuous integration (CI) and continuous delivery (CD) are supported by most of the private and public cloud service providers. This ensures centralized governance and control, in addition to reducing the costs associated with DevOps automation on-premises. DevOps utilizes orchestration systems that can proactively monitor the cloud data sets and application workloads. End-to-end automation is a prerequisite for deriving the full advantage from the cloud.

    By expanding the concept of continuous improvement to cloud-based platforms, DevOps ensures lesser system vulnerabilities and greater security.

    DevOps Best Practices for Effective Cloud-Based Computing

    DevOps provides several core capabilities that assist organizations in effectively handling cloud challenges. These include:

    • Infrastructure as Code (IAC): IAC comprises the provisioning of servers and installation of application code, the core components of the system architecture.
    • Automated Application Deployments: DevOps practices facilitate the creation of a fully automated application deployment pipeline that is of great importance in the development life cycle.
    • Application Lifecycle Management (ALM): DevOps principles such as continuous integration and delivery help in effective ALM in the cloud.
    • Continuous Quality Assurance (QA) and Testing: DevOps capabilities address the challenges for QA and testing in the cloud by provisioning multiple test environments using cloud-based resources that result in enhanced quality and productivity.
    • Knowledge-Sharing with the Cloud Provider: DevOps promotes the concept of knowledge sharing between organizations and SMEs of the cloud service providers throughout the application life cycle using online communities that are focused on fostering communication and collaboration, thereby ensuring that most risks are mitigated effectively.

    The Significance of Cloud Computing vis-á-vis DevOps

    Cloud computing complements DevOps in several ways. The application-specific infrastructure in the cloud enables developers to own more components easily and enhance their productivity and efficiency. It allows developers to create the development environments quickly without the need for IT operations to provision resources and infrastructure.

    Cloud computing ensures flexible IT infrastructure in addition to enabling greater business agility. It propels IT transformation by helping organizations in streamlining and embedding DevOps processes.

    DevOps tools and services eliminate human error and help in establishing repeatability by automating and streamlining the process of building and managing code.

    IT Transformation Enabled by DevOps with Cloud Technology

    Cloud computing coupled with DevOps ensures that scalability becomes an integral part of application development, thereby contributing to reduced infrastructure costs and increased global reach.

    Cloud-based operations increase the availability and failover ability of applications in addition to eliminating downtime, which leads to improved business reliability and rise in customer satisfaction.

    DevOps automation and IAC help in reducing the complexity of the cloud and improving system maintenance. Additionally, the automated repeatable processes increase security controls. Process streamlining and faster access to the development environments ensure improved product time to market.

    In Conclusion

    By realizing the importance and prioritizing the usage of DevOps in the cloud, organizations can derive a huge number of potential benefits including enhanced agility and reduced operational costs.

    — Veritis

  • IBM Unfurls Cloud Platform for Building Microservices

    IBM Unfurls Cloud Platform for Building Microservices

    IBM has unveiled a new development environment in the cloud designed to make it easier to build microservices.

    John Duimovich, IBM CTO for Java, said Microclimate provides a complete framework building applications based on microservices written in Java, Node.js or Swift.

    Microclimate runs on an instance of IBM Cloud Private, a private cloud based on Docker containers that is hosted on the IBM public cloud. Once those applications are developed, organizations can either deploy them on-premises or in a public cloud of their choice.

    Microclimate makes use of Kubernetes and Docker containers to create and orchestrate the microservices development process, which can quickly become a complex endeavor. Because of the issue, Duimovich said, more organizations will be pushing development of microservices into cloud computing environments that provide access to what amounts to a turnkey application development pipeline.

    Duimovich noted it’s possible to more closely mirror the production environment an application will be deployed on using compute resources that can be invoked on demand. Instead of developing an application on a laptop, developers can stress test microservices in the cloud by, for example, engage in “chaos monkey” testing, wherein developers allow a microservice to fail to see how the overall application reroutes requests to other microservices, said Duimovich.

    Developers also can engage in A/B testing in a way that would not be economically feasible to engage in when applications are developed on-premises simply because of the amount of additional IT infrastructure that would have to acquired and provisioned, said Duimovich.

    The cloud also makes it easier for teams of developers to collaborate on the development of microservices-based applications regardless of geographic location, Duimovich added. Developers may still choose to write code on their local PC, but when it comes time to load it into an application, the Microclimate platform makes it easier for everyone on the team to observe how that microservice behaves within the context of a larger application.

    IBM will also make available diagnostics tools to enable developers to more easily discover why their applications might be behaving in a certain way.

    While not every application may lend itself to being constructed using microservices, many organizations are now concluding they are simply a better way to develop reliable software. In addition, developers can be given ownership of specific sets of microservices end to end, which not only gives them more control but also makes them accountable for their overall quality. Of course, building applications made up of hundreds of microservices is going to require organization to implement DevOps best practices, which Duimovich said IBM is more than willing to share with customers.

    No one knows for sure when most applications running in a production environment will be made mainly of microservices. But given the rate at which they are now being used to develop applications, it’s now only a matter of time before such applications become dominant.

    — Mike Vizard

  • A Saner Way to Build a DevOps Cloud

    A Saner Way to Build a DevOps Cloud

    There’s a popular definition of insanity: doing the same thing repeatedly but expecting different results. Yet, too many enterprises implementing digital services and apps in the cloud fail to heed this warning as they turn to point-to-point integration of their cloud components. In the process, they’re introducing tremendous complexity that looks eerily similar to the point-to-point application integration headaches companies faced before the concept of centralized mediation emerged some 15 years ago.

    Consider the scope of the challenge. A cloud deployment can contain 30-plus product components that need to be integrated to run together smoothly. At any time, an update to one of these products can break processes that rely on the other components. DevOps compounds the complexity, since teams need to ensure consistency across development, test and production environments. It may be fine for a dedicated DevOps team in the group to handle these environments when there’s just one project. However, as the number of applications utilizing cloud technology grows, it is expensive to have DevOps teams build each environment as a wild west project.

    Standardizing on Stacks

    A saner approach is to implement a cloud architecture that standardizes on stack-level operations. Implemented effectively, a stack serves as the reference architecture for all the components and automation needed to create a replica of your production environment. This “full stack” is in essence much like the configuration management database (CMDB) once thought to be the holy grail of enterprises.

    With a meta-description of your full stack for a service or application in place, it becomes possible to deploy identical copies for development, test and production, as well as automate DevOps across your application. This ability to duplicate stacks removes the barriers to, for example, deploying multiple test environments or multiple copies of the stack for security compliance or disaster recovery.

    The stack is an important concept for understanding how you are building and running your software. If something goes wrong, it also provides visibility into what is running, how it was deployed and what the problem might be, facilitating the ability to systematically correct the problem and deploy the fix to all needed replicas. Developing a stack concept also lets you track applications—plus the associated tools, development practices, cloud practices and vulnerabilities—across your organization, providing a critical step in the maturity of your enterprise’s cloud development.

    Standardizing on stacks enables development teams to focus on building new applications and services rather than spending six to 18 months implementing the cloud architecture. At the same time, different groups may require different capabilities, making a one-stack-fits all-approach impractical. The middle ground is to provide a set of “sanctioned stacks” or a portal for configuring stacks, which limits options to products that have been pretested to confirm they work together.

    Structuring DevOps Cloud Stacks

    A DevOps cloud architecture will consist of at least two main stacks: the core infrastructure stack and the DevOps stack. Increasingly, these stacks run in containers, which provide two key advantages: a greater agility through the ability to spin up apps faster and more cost-effective use of resources through operating system-level virtualization.

    The core infrastructure stack supports a service or application with services that ensure security, reliability and scalability. It includes cloud infrastructure, such as networking and storage, which may be handled by a public cloud platform or a private cloud, along with container-specific functionality, such as a Docker runtime with orchestration provided by Docker Swarm or Kubernetes. The stack also has a layer for handling performance and management, including networking, load balancing, service directory, log management, monitoring, backup and recovery and vulnerability scanning, which are supported by a range of different products.

    At the top of the core infrastructure stack is an application layer or stack that includes development tools, such as Java Stack or Node.js Stack. More advanced application stacks will go beyond tools to provide the blueprints for migrating from monolithic apps to containers and microservices.

    The DevOps stack supports continuous integration/continuous deployment (CI/CD). It runs across multiple infrastructure stacks and codifies the tools, processes and procedures to test and deploy or rollback changes to the infrastructure stacks. It typically incorporates DevOps instructions using Chef or Terraform, Ansible, Puppet, Swarm, Helm and half a dozen other tools. Because automated testing is critical, DevOps stacks also should include tools that help with development, building, integration, automated testing. Popular options include WireMock and Selenium for testing web apps and services, Artillery for performance testing and Blackduck or Clare for security testing.

    Additionally, there are key functions within the DevOps cloud platform that extend across development, test and production stacks. These include security, a catalog of stack templates, a registry for certified containers and usage data collection to apply predictive analytics for performance and cost optimization.

    Introducing Stack Automation

    Enterprises implementing a DevOps-enabled cloud need to consider automating as many processes as possible, particularly for large installations. For example, a bank may have 150 to 200 groups developing applications. With each app requiring environments for development, test and production, that means anywhere from 450 to 600 deployed stacks to maintain.

    Significantly, updating stack components needs to be a coordinated process. It’s not enough to rely on automated upgrades and security patching provided by individual product vendors. That’s because if the upgrade or patch changes something that affects a component in the enterprise’s stack, the vendor probably doesn’t know that and this may break the stack.

    Automating stack functions in a coordinated way is best accomplished using an intelligent, centralized “command center” portal that incorporates a central orchestration hub. This eliminates much of the complexity associated with manually running multiple scripts by performing whole operations on a stack. Whether your organization builds it or you use a third-party solution, this hub for automating the execution of scripts should incorporate an orchestration engine, visual map, domain model, proactive monitoring and cost analysis.

    Importantly, a command center incorporating an automation hub lets you take advantage of improved visibility provided by stacks to track and report on cloud costs. Moreover, you can capitalize on “spot” instances—costing five to 10 times less than persistent instances—by using the hub to automatically handle periodic interruptions and redeploy the components taken away.

    Through automated stacks, your organization now has a sane way to cut the complexity of implementing a DevOps cloud while providing an agile platform to support your development team’s innovations.

    — John Mathon

  • 3 Ways to Minimize the Impact of High Severity Incidents

    3 Ways to Minimize the Impact of High Severity Incidents

    According to Information Technology Intelligence Consulting Research, 98 percent of organizations report that a single hour of downtime can cost upwards of $100,000. That doesn’t take into consideration the long-term effects on brand, potential loss of trust with existing customers and engineering time. This is why making sure high severity incidents are resolved quickly and safely is extremely important.

    Here are three simple yet effective ways to minimize the impact of high severity incidents within your organization:

    Establish an Incident Manager On-Call Role and Rotation

    One of the most impactful ways to help deal with high severity incidents is by establishing an incident manager on-call (IMOC) role and rotation. The IMOC is responsible for resolving high-severity incidents in a safe and fast manner. IMOCs are responsible for the management of high severity incidents through their life cycle: detection, diagnosis, mitigation, prevention and closure. As such, the IMOC role provides everyone in the company with a single point of contact. Ultimately, the IMOC role leads to a significantly reduced mean time to resolution (MTTR) for SEVs.

    Identify and Assess Your Critical Services

    Does everyone in your company know what your top five most critical services are? Take a proactive approach to improving your overall reliability by making a determination and reliability assessment of these services a top priority. It is important to understand your system and recognize how critical service failures could result in high severity incidents. Reducing downtime is certainly a goal every engineering team should have, but the fact is, things inevitably go wrong.

    Practice Chaos Engineering

    Chaos engineering is the practice of performing thoughtful, planned experiments designed to reveal the weakness in our systems. While it may seem counterintuitive, like a flu shot it helps to be proactive now to prevent something more harmful in the future. By having a better understanding of your system’s weaknesses, you’ll be able to more effectively troubleshoot issues and minimize the impact on your customers. Chaos engineering will empower you to identify weaknesses before they become SEVs.

    In Conclusion

    Implementing an IMOC role and rotation, identifying and assessing your critical services and implementing chaos engineering are three ways you can minimize the impact of high severity incidents, keeping your business running smoothly even when things aren’t.

    — Tammy Butow

  • NATS Messaging Entering Cloud Native Purview

    NATS Messaging Entering Cloud Native Purview

    The Cloud Native Computing Foundation (CNCF) has expanded the scope of its purview by adding open source NATS messaging software to an expanding list of technologies it now oversees.

    NATS messaging software has been commonly employed in environments such as platform-as-a-service (PaaS) environments. But with the rise of microservices, a campaign to make NATS a part of the portfolio of technologies that members of CNCF consortium will advance has begun in earnest, said Derek Collison, who lead the development of NATS and is now CEO of Synadia Communications, which is dedicated to enabling organizations to more easily deploy and manage messaging systems based on NATS.

    The ultimate goal, Collison said, is to not only make messaging ubiquitous, but also effectively invisible.

    Collison said he and the CNCF envision a world where messaging just comes baked into every application. PaaS environments may have driven mainstream adoption of NATS messaging to integrate various elements of an application, but microservices will make messaging a fundamental requirement for building applications that can efficiently scale, he said, adding too many organizations already run into these issues because they are depending on HTTP to integrate various microservices.

    NATS is already widely employed by a number of vendors and organizations including Apcera, Apporeto, Baidu, Bridgevine, Capital One, Clarifai, Cloud Foundry, Comcast, Ericsson, Faber, Fission, General Electric, Greta, HTC, Logimethods, Netlify, Pex, Pivotal, Platform9, Rapidloop, Samsung, Sendify, Sensay, StorageOS, VMware Acadiant, Weaveworks and Workiva.

    The core NATS server and NAT Streaming software are maintained by Synadia. There are clients for Python, Ruby, Node.js, Elixir, Java, NGINX, C and C#, as well as third-party contributions that add support for Arduino, Rust, Lua, PHP, Perl and others.

    Longer term, Collison sees NATS evolving to include functionality to support real-time applications, many of which today are using Apache Kafka software. Rather than having to deploy NATS and Kafka for different use cases, Collison said it will make more sense to have a common control plane to address multiple classes of use cases for messaging.

    Messaging systems in one form or another have been at the heart of integration platforms for decades now. But the assumption was always that integration would be addressed after the applications were deployed. In the future, the assumption is that all cloud-native applications need to be integrated, which is much easier to accomplish if they all come with some form of messaging capability baked in. Integrating and managing federated instances of messaging systems still will be required. But much of the lower-level functions now being centrally processed will be pushed out into the applications being integrated.

    Collison is the first to admit that messaging is not some new, emerging technology. But as microservices architectures continue, messaging will prove to be core to a new generation of cloud-native applications, he said. The CNCF is clearly betting that a consortium of vendors working on a common code base for messaging will accomplish that goal a whole lot sooner.

    — Mike Vizard