devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Finishing the Pipeline: Monitoring, Tools, Automation and …

    Finishing the Pipeline: Monitoring, Tools, Automation and …

    It is true that DevOps has grown to be the beast in the room. I’ll co-opt the “cloudwashing” term to call it “DevOps-washing” because it seems every tool you’ve ever used to develop and deploy applications now has a DevOps angle to it. For example, the Jenkins update center is kind of overwhelming. While I can’t be certain, there’s a chance that our new coffee maker has a plugin for Jenkins.

    But it’s also true that DevOps really is coming of age. The success of Jenkins is largely based on CI/CD, and the tools built both up and downstream from it are folding in more and more of the DevOps process, making life easier—if not exactly easy—for IT.

    Even with platforms, the choices are growing and the automation is, too. Whether one of the major cloud vendors, where deployment can be fully automated or hyperconverged infrastructure and where deployment can be fully automated, we’re moving toward a future of not caring about physical infrastructure but rather, “Can I get a connection to it?” Of course, it’s not that simple, but running Docker or Kubernetes on hyperconverged infrastructure means we have on-demand deployment, and the cloud does much the same.

    Tooling for monitoring is also getting better, whether you are monitoring user experience or a particular API’s CPU usage. For the most part, we are not yet to the point where automation can deal with the majority of alerts from monitoring, but that boundary is being pushed daily. We certainly can tool our systems—both the infrastructure and the app sides—to offer us more data about application health than we’ve been able to get in the past. From physical hardware all the way up through containers we have a wealth of options for monitoring, and application monitoring is getting even more attention than infrastructure monitoring.

    Heading Down the Trail: Monitoring and More

    Which leaves one wondering where this is bound. Let’s assume that the areas that are a bit behind—like over-arching network configuration from ARA tools—catch up. They will, and that’s pretty obvious, so I’m trying to remove the short-term roadblocks to talk about what we might be planning for and facing moving forward.

    If we can assume a place to deploy that has reasonably unlimited capacity—such as the cloud, where cost is the limit, or hyper-converged, where capacity is a limit but expandable in chunks—and we can assume that ARA is running the Dev/Test side, then pairing it to a preferred server configuration (be that VM or container, depending on app, group, company, etc), and pushing out the deploy, then we’re left with the monitoring piece, and automating the responses to monitoring issues. That is growing, too.

    Right now, the standard in the DevOps world for a server that is malfunctioning in some way is to kill it and start a new instance. This often masks real-world problems, and if it appears to “fix” the problem, reduces the priority of resolving what went wrong. This is, in a nutshell, the real error for Cloudbleed. They were seeing servers spew errors, when one appeared to core, they simply started another. It allowed a simple programming error to persist over months and become a security issue.

    So the next great leap will be to find a quick way for monitoring to determine exactly where problems are occurring, and force a developer to fix it. There are tools that can auto-generate bug reports, but they’re rudimentary at this point in time, and we need them to be more advanced. There will also always be the trade-off of how much in resources you use for monitoring when the point of the app has nothing to do with monitoring. And like so many things, the hidden cost of keeping that monitoring up to date will be a technical debt—one of many that the DevOps community seems slow to acknowledge.

    There Always Seems to be More

    On the “time we waste” side, the fight over internal/external needs to end. The fact is that internal cloud isn’t going anywhere anytime soon, and if you’re running in containers, you don’t have to care. My company is currently looking at a tool that can run hundreds of containers in a very (physically) small space. We can deploy to the cloud or deploy there, as long as we have container templates. It doesn’t matter what the business need forces us to use; containers really will run pretty much everywhere. It does no one any good, harping about internal/external. A deployed app is a deployed app.

    Now, talking about the differences in networking between internal/cloud, external/cloud, and container manager (regardless of where it sits): That is a discussion worth having.

    — Don Macvittie

  • DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    In this DevOps Chat we speak with Steve Boone, product owner and development manager for Urban Code Deploy. Now that DevOps is in practice at more organizations, measuring DevOps success is a question many are asking. Steve has helped hundreds of companies adopt, implement and scale their agile and DevOps practices as part of their digital transformation. Steve gives us some insights into how can you measure your DevOps success.

    As usual the streaming audio of our chat is below. Following that is a transcript of our conversation to follow along.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 117787″ width=”100″ height=”100″] Steve Boone
    Steve Boone is a DevOps SME at IBM. He has helped hundreds of companies adopt, implement, and scale their agile best practices including CI, CD, Environment Provisioning, and Application Release Automation. Steve is currently the Product Owner & Development Manager for IBM UrbanCode Deploy.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to be joined today by Steve Boone. Steve is the Product Owner and Development Manager for IBM UrbanCode Deploy, one of the leading CI/CD solutions in the market. Steve, welcome to DevOps Chat—how are you?

    Steve Boone: Doing great, Alan. Thank you so much for having me today.

    Shimel: Great. Steve, I wanted to talk to you—well, about a couple of things today. But let’s focus in first on, I’m just back from another major conference, and once again I’m—not amazed, because by this point, it’s expected. But still, you know, going strong, the biggest thing we get, or the biggest feedback that I hear from organizations looking to do DevOps transformation is—hey, this all sounds great, it sounds really good, but how do we know, you know, first of all, how do we get started with our DevOps transformation, and then once we’re doing it, how do we know it’s working? Right? How do we measure the ROI, or even if we can’t get to a real ROI, how do we measure progress? What does success look like?

    And I would imagine, you know, the guys at UrbanCode, the team at UrbanCode has been dealing with this for some time. What do you tell people?

    Boone: Yeah, that’s a great question, and it’s—you know, I think it’s a little different for everyone. And when we start looking at measuring success and first finding out, you know, where do we start, a lot of times we’ll work with customers to identify, you know, what are your problematic areas? There’s a lot of aspects to DevOps, it’s not all CI/CD, there could be aspects of agile planning, there could be release management. There’s a number of different things that come into play.

    So, we usually sit down and try to focus on, you know, where do you think your bottlenecks exist today, and then start to address those. But when we went to measure—and you know, you’re right, the allure of DevOps comes with all of this ROI promise, right, where if we do these things and we change our people and our process and our tools, we’re gonna be better off for it, the business is gonna be better off for it.

    So, how do we then make sure that’s actually happening, right? That the time and energy that I’m putting into changing my processes are actually showing me that ROI.

    So, what we’ve seen a shift in the industry towards is really starting to gather the different sets of metrics that are coming from, really, the end to end products that we’re dealing with in DevOps whether it’s your build tools, your testing tools to understand what I’ll all our key metrics. So, you know, if in fact we are capable of speeding up our delivery to our pipeline, we should be getting to market faster, right? So, we look at statistics like cycle time—how long does it take for an application or a release of application to go from dev to prod? And then we look at that data over time. Is it, in fact, improving? And if not, we want to identify other bottlenecks that are kinda holding that progress up.

    So, if I look at a set of components that make up an application and I see that the majority of those components have a really good cycle time, you know, we’re only as fast as our weakest link. So, if the database component, for example, is routinely slower to get through QA than the rest of the component, that’s going to slow down our time to market and therefore gonna slow down our release.

    And the beauty is, in turning on the flashlight, so to speak, so that you can see that data and actually do something with it, a lot of times we look at it and say, “Well, we know we have automation and therefore we know we’re going faster.” But that just might mean we’re going to QA faster or we’re going to dev faster. We want to make sure that we’re actually getting that ROI, so if we can set baselines with teams and say, “Hey, prior to doing this automation, it took you four months to get from dev to production out the door, right? This past release cycle we did it in three and a half months—great. What is that time savings? What does that time savings mean in cost?”

    And, we’re starting to see a big trend within the industry of many different companies starting to put together products to start to track these. So, I think it’s a whole new area for us to focus on, and in hopes—what we’re trying to share with customers is that, look, not only are the changes in people and process that you’re making working, but the tooling is working, and hey, here are some areas where you can improve those processes.

    Shimel: Yeah. So, Steve, obviously, I want to—you said a mouthful, there. [Laughter] But let me focus in on one thing you said that I want to re-emphasize to our audience, and that is, you know, DevOps is so much more than CI and CD, right? There’s config management, there’s APM—there’s a lot that goes into this umbrella term that we call DevOps, and it seems to be growing every day.

    That being said, though—you know, I once heard someone describe DevOps is the symptom and CD is the cure. So, you know, I don’t want to minimize the importance of CI/CD, but you know, automation—there’s so much that goes into this equation or this term that we call DevOps. And I think that’s—you know, Steve, it’s almost like it’s its greatest asset but it’s also its greatest liability, you know what I’m saying?

    Boone: Yeah, there absolutely is. I think that a lot of times, we definitely see, when people are talking DevOps, their focus tends to be on CI/CD. And I think that’s because, you know, out of the gate, especially if you’re just starting off, it’s kind of your biggest bang for your buck, right? You can get a lot of fast return on investment just by improving your processes and automating them and making them consistent.

    As we see teams mature, and as they transition into a more Enterprise wide DevOps solution, then we start to see—well, where are the real boundaries in my organization, right? Is it, we see a growing trend where app dev teams are focusing on automation, but there’s a whole different silo in infrastructure, you know? So, an app dev team wants to request an environment to do some testing in—they have automation, and the tools that they have for automation could easily provision that environment. But the business dictates that that’s the infrastructure’s just, and they have a completely different set of tools that they use for that, right?

    And so now we get into this challenge of really continuing to try to break down these barriers to make sure that these assets and tools that are out there can work together, and that there’s clear cut guidelines on that.

    So, yeah, I think it is a blessing and a curse, right? Because when we start thinking about DevOps, everybody wants that—you know, we’re a culture of having that instant gratification. So, it’s nice that we can get that with deployment automation and build automation and test automation. But we need to be looking ahead to the future, which is gonna be—hey, I’m gonna provision these things on demand and make these environments available to my teams, and today we use Amazon for that. What happens if, six months from now, we have to change and we need to support Azure or Google or SoftLayer or Bluemix, right? We need portability, we need full stack provisioning and config management on that.

    And that’s—I think that’s something that, a lot of times, people just starting out, they don’t look too far ahead. And my suggestion to folks is—hey, it’s okay to take that first step. You should be cautious about the first step, but keep in mind where you wanna be two years from now, three years from now, five years from now. What’s your DevOps end goal?

    Shimel: Yeah. You know what? So, Steve, I think that might be the first question we need to—especially for consultants out there who may be listening to this. You know, whether you work for an IBM or a small consultancy, I think that has to be the first question. You know, people come and say, “I want to do DevOps.” You gotta ask them, what’s the end goal, here? What’s the end game? Why? And that’s a huge piece of it.

    Steve, if I can, I’d like to turn to a little bit more about UrbanCode and, you know, UrbanCode’s kind of a unique animal, if you will, in that, you know, it was one of the earliest, earliest kinda startups playing in the CICD space, right? And so it had that whole startup culture, if you will, the startup thing going on. And then, of course, you know, acquired by IBM and really become a linchpin of, you know, IBM’s DevOps, and not only DevOps, but you know, in IBM, as you know, DevOps is tied into cloud and hybrid and Bluemix and SoftLayer and all the things you mentioned. You know, it’s such a critical piece of that puzzle.

    What is happening lately with UrbanCode? I saw Gartner give you guys some accolades recently.

    Boone: Gartner gave us some accolades. We scored very well, as well, on the Forrester Wave that just came out.

    Shimel: The Forrester—yes.

    Boone: We were named as a leader in the—yep, in the Forrester Wave. So, that was exciting. It was a great score for us. We’re about as far right in that quadrant as you can be.

    And there’s a lot of really good things coming out. I think the reason we scored so well is that they’re looking at the strategy within UrbanCode and seeing that, you know—as you mentioned, this isn’t our first trip around the block. We’ve been helping customers do this for over 10 years. And for us, you know, we work with companies that are small startups to everything that are enterprise financial institutions and healthcare and government agencies.

    So, there are, at any given time, different, I’ll say, business focuses that are in a different spot of transition. So, I can go to an enterprise and talk to 30 different groups and organizations in that enterprise—they’re all in a different maturity, they’re all in a different level and area of that DevOps transformation. But what we’re able to do is, we have a solution that can help everybody regardless of where they’re at, and as they mature together over time, ultimately help them reach the goal where the company wants them to be.

    You know, some of the new things that we’re focusing on—you know, last year, part of our vision, we had announced at Interconnect our DevOps Insights product as well as our continuous release product that are focused on helping customers one, transition into DevOps, do a lot of that deeper reporting and ROI analysis on where they are in their transformation, but as well as help companies manage to the cloud and for the cloud.

    What I mean by that is, you know, today, we talk about cloud like it’s ours, but for large enterprises, it’s still very much a challenge. You know, it’s hard for a team to just go request access and say, “Hey, I’m gonna push my data to the private cloud.” There’s still a lot of—or even public cloud, whatever it might be. There’s still a lot of hurdles to that.

    So, what we’re trying to do is, as teams embrace this and they’ve got deployments going on-prem and off-prem, how do we organize that? How do we have visibility and traceability and understand as you’re taking large applications and breaking them down, let’s say, into microservices? You know, some of those applications are easy to re-architect, some are not. And sometimes you’re left with applications where you’ve only got maybe three quarters of that application re-architected, or you’ve got databases that are always gonna be on-prem, or you’re using mainframe services.

    And that’s really where the UrbanCode products excel, is allowing you to really deploy anything, anywhere, but also have a cohesive look at, what are the interrelated appendices of those parts? If something on my backend mainframe changes, how is that affecting the things that I’ve deployed into my mobile app? And if something needs to fall out of just release, you know, what’s the impact, even? How is that gonna affect business? And I think those are some of the main reasons why we scored well within the Forrester Wave and why they marked our strategy so high.

    Shimel: Absolutely. You know, Steve, we’re coming up on the end of our allotted time, unfortunately, but I wanted to mention one thing if we can talk about it, and that is that you spoke about Interconnect, which has been the big IBM DevOps related show, as well as other technologies for the last couple years. This year, IBM is kinda consolidating a lot of the shows they do into a pretty big mega-event called Think 2018, and of course, that is gonna be once again at the Mandalay Bay in Vegas, and it’s happening March 19th to the 22nd. I believe the call for speakers has just opened, and I’ll put some links in the show notes so that people can, if they wanna speak or if they want to attend the event would be great.

    But in any event, what’s UrbanCode’s plans around Think 2018?

    Boone: Yeah, thanks. I hope folks do and are able to register and come out. It’s going to be a fantastic show, and it is very much a mega show for us. So, we’ve taken—I believe there’s 11 different topics that really, I’ll call them focal points or even think of them as investments within IBM. Everything from cloud to Watson to mobile to security, internet of things—there’s a number of different topics going on at this.

    UrbanCode will be under the cloud focus, and we’ll—underneath the cloud topic, there’s a section specifically for DevOps. So, if that’s what you’re interested in, come out and check us out—we’ll be there. We’ll be talking about our latest release that we’ll have done at that time, and we’ve got a lot of really cool features that were actually in development and testing right now that we plan to announce at the Think conference, so without be demo-ing those, and we’ll have—as always, have a bunch of UrbanCode customers there sharing their ideas, sharing their experiences, and really helping educate how they’ve transformed their business.

    And I think what a lot of folks will find appealing is that it’s never a one tool solution, right? And that’s one thing I always encourage folks is, when you’re trying to be in a DevOps transformation, a single product, a single methodology—it’s not gonna do it. You really need to embrace the various tools that are in the market, you need to embrace existing tools that are already in your company, and these are gonna be working examples and explanations of how some of the top companies in the world are doing just that using UrbanCode and using a variety of tools that we support.

    Shimel: Absolutely, absolutely. Alright, Steve, we’re actually way over time, I apologize, but I think we got some good information here that people will be interested in. I want to thank you for being our guest this week on DevOps Chat and invite you back soon. We want to hear more about Think 2018 as we get closer as well, but good luck with UrbanCode, Steve, and we’ll speak to you soon.

    Boone: Hey, Alan, thank you. As always, appreciate you having me today.

    Shimel: Alright. Steve Boone, Product Manager, UrbanCode Deploy—or Product Owner, excuse me, UrbanCode Deploy. Thanks for being our guest on this DevOps Chat. This is Alan Shimel, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • Platform9 Brings Workflows to Serverless Computing

    Platform9 Brings Workflows to Serverless Computing

    Serverless computing frameworks are widely regarded as the next big thing in enterprise IT because they are based on an event-driven architecture that makes servers, storage and networking resources dynamically available as needed using a programming construct known as functions. But DevOps teams are challenged in finding a way to orchestrate all those functions in concert with one another.

    To enable the orchestration of those functions, Platform9 has added support for Fission Workflows to its instance of a serverless computing framework. Platform9 CEO Sirish Raghuram says Fission Wokflows will make it possible for IT organizations to craft complex applications made up of thousands of functions.

    On the one hand, serverless computing frameworks promise to make DevOps easier by eliminating the need to provision infrastructure every time a workload exceeds whatever amount of capacity that has been assigned to it. On the other hand, attempting to manage what could easily become thousands of functions in an IT environment is likely to make DevOps even more challenging than it is today. While not a new concept, Raghuram says Fission Workflows provides IT organizations with a familiar construct for managing functions.

    Benefits of Fission Workflows include an ability to reuse functions as well as being able to upgrade entire related sets of functions all at once. There are also fault-tolerant capabilities that make possible to recover and restart a workflow in the event of an infrastructure failure.

    Platform9 is specifically making the case for a serverless computing framework based on Kubernetes clusters that can be deployed on-premises or in the cloud. Platform9 also provides support for containers on an instance of Kubernetes, and Raguham says the company expects that IT organizations will mix and match containers and serverless computing frameworks as they see fit. For example, a container might invoke a function via an API call to run a stateless process while Docker containers are employed for all the stateful processes that require access to primary storage, he says.

    Raguham notes the trouble with serverless computing frameworks put forward by cloud service providers such as Amazon Web Services (AWS) is that they lock an IT organization into a specific platform instead of taking advantage of a portable cluster technology such as Kubernetes, which is backed by the Cloud Native Computing Foundation (CNCF). Kubernetes also provides the added benefit of a common platform for both containers and serverless computing, he says.

    It’s still early days for the use of serverless computing frameworks in the enterprise. Nevertheless, it’s clear they will need to be managed from a DevOps perspective alongside cloud-native applications running on containers and platform-as-a-service (PaaS) environments and legacy applications running on virtual machines and bare-metal servers. Given the fact that none of these architectures is likely to supersede any of the others anytime soon, IT organizations would be well-advised to start crafting a DevOps strategy now on the assumption that the overall IT environment is about to become even more complex.

    — Mike Vizard

  • With a Multicloud Infrastructure, Control is Key

    With a Multicloud Infrastructure, Control is Key

    Ask any developer or DevOps manager about their first experiences with the public cloud and it’s likely they’ll happily share some memories of quickly provisioning some compute instances for a small project or new app. For (seemingly) a few pennies, you could take full advantage of the full suite of public cloud services—as well as the scalability, elasticity, security and pay-as-you-go pricing model. All of this made it easy for teams to get started with the cloud, saving on both the IT budgets and infrastructure setup time. Public cloud providers AWS, Azure, Google Cloud, Rackspace and others made it easy to innovate.

    Fast forward several years and the early promise of the cloud is still relevant: Services have expanded, costs have (in some cases) been reduced and DevOps teams have adapted to the needs of their team by spinning up compute instances whenever they’re needed. But for many companies, the realities of their hybrid-IT infrastructure necessitates support for more than one public cloud provider. To make this work, IT Ops needs a control layer that sits on top of their infrastructure, and can deliver applications to customers over any architecture, including multicloud. This is true, no matter what the reason teams need to support multi-cloud environments.

    Prepare for the Worst

    As any IT Ops manager, or anyone who has lost access to their web app knows, outages and cloud service degradation happen. Modern Ops teams need a plan in place for when they do. Many companies choose to utilize multiple public cloud providers to ensure their application is always available to worldwide customers, even during an outage. The process of manually re-routing traffic to a second public cloud in the event of an outage is cumbersome, to say the least. Adding an app delivery control plan on top of your infrastructure allows companies to seamlessly and automatically deliver applications over multiple clouds, factoring in real-time availability and performance.

    Support Cloud-driven Innovation

    Ops teams often support many different agile development teams, often in multiple countries or from new acquisitions. When this is the case, it’s likely that the various teams are using many architectures on more than one public cloud. Asking some dev teams to switch cloud vendors is not very DevOps-y. A better option is to control app delivery automation with a cloud-agnostic control plane that sits on top of any cloud, data center or CDN architectures. This allows dev teams to work in their preferred cloud environment, without worrying about delivery.

    Avoid Cloud Vendor Lock-in

    Public cloud vendors such as Amazon Web Services or Microsoft Azure aren’t just infrastructure-as-a-service (IaaS) vendors, they sell (or resell) products and services that could very well compete with your company’s offering. In the beginning, using a few cloud instances didn’t seem like such a big deal. But now that you’re in full production and depend on one of these cloud providers for your mission-critical app, this no longer feels like a great strategy. Adding a second public cloud to your infrastructure lessens your dependence on a single cloud vendor who you may be in “coopetition” with.

    Multiple-vendor sourcing is a proven business strategy in many other areas of IT, giving you more options during price and SLA negotiations. The same is true for IaaS. Cloud services change often, as new services are added or removed, and price structures change. Taking control over these changes in public cloud service offerings, pricing models and SLAs is another powerful motivator for Ops teams to move to a multi-cloud architecture. An application delivery automation platform that can ingest and act on cloud service pricing data is essential.

    Apps (and How They’re Delivered) Have Changed

    Monolithic apps are out. Modern, distributed apps that are powered by microservices are in. Similarly, older application delivery controllers (ADCs) were built for a static infrastructure world, before the cloud (and SaaS) were commonly used by businesses. Using an ADC for application delivery requires a significant upfront capital expense, limits your ability to rapidly scale and hinders the flexibility to support dynamic (i.e. cloud) infrastructure. Using ADCs for multiple cloud environments compounds these issues exponentially. A software-defined application delivery control layer eliminates the need for older ADC technology and scales directly with your business and infrastructure.

    Regain Control

    Full support for multicloud in product may sound daunting. After all, Ops teams already have plenty to worry about daily. Adding a second cloud vendor requires a significant ramp-up period to get ready for production-level delivery, and the new protocols, alerts, competencies and other things you need to think about. You can’t be knee-deep in the details of each cloud and still manage infrastructure. Adding in the complexity of application delivery over multiple clouds can be a challenge, but much less so if you use a SaaS-based application delivery platform. With multicloud infrastructure, control is key.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services and Microsoft. Connect with him on LinkedIn.

     

  • Is AWS Cloud Per-Second Billing Boon or Bane for DevOps Engineers?

    Is AWS Cloud Per-Second Billing Boon or Bane for DevOps Engineers?

    Amazon’s introduction of its AWS services in 2006 with a per-hour billing model for compute resources was a game-changer for the IT world. Since then, AWS has taken over the cloud computing market as a leader, while broadening the range of cloud services offered every year. However, the per-hour billing business model was one of the major issues for many customers—in particular, those who had applications using EC2 for only minutes at a time.

    Recently, AWS announced support for per-second billing of its EC2 service, addressing the aforementioned concerns. Of course, this also created controversy among the per-hour supporters. While I won’t get into the pros and cons across the whole enterprise, one group in particular is affected from the new per-second model: DevOps engineers.

    Here are the top five implications for DevOps teams as a result of per-second billing:

    Autoscale without worrying about cost

    Most engineers were vary of autoscaling at will, mostly because of EC2’s hourly charges even though they might need additional compute capacity for just 15 minutes. With per-second billing, DevOps engineers don’t have to worry—it’s as simple as scaling your EC2 instance as you need to, and when you need to.

    No more custom logic for hourly batches

    Many customers use EC2 for jobs and batch processing purposes. Due to the hourly pricing, engineers have written custom logic to benchmark and constantly tune the number of nodes in their batch clusters to ensure they are cost-optimized. Per-second billing frees up headaches for DevOps engineers that are using EC2 for batch processing and job clusters.

    The need to speed up EC2 launches

    With per-second billing, it’s important to take advantage of prebaked Amazon Machine Images (AMI) for launching your EC2 instances, instead of complete configuration setup on every instance launch. This will reduce the costs for you, by saving anywhere from five to 15 minutes. It’s time to create prebaked AMIs for faster instance launches, ultimately saving costs.

    Dilemma of Lambda or EC2

    Be prepared to compare whether to use Lambda or EC2 for new workloads and applications more often than you are used to. Your benchmarking between Lambda and EC2 has become a little more dicey. The serverless lambda just got competition from EC2 again.

    Your big data just got easier

    With EMR also supporting per-second billing, your job has become a lot easier. As a , you no longer need to constantly benchmark your EMR clusters for number of nodes and job processing times to be optimized for per-hour billing.

    DevOps engineers have a lot to benefit from per-hour billing, but also much to consider when it comes to time-to-deployment and choosing a compute service. Now is the the time for DevOps engineers engineers to bring these concerns to their CIOs to make a smooth transition to the new AWS business model.

    About the Author / Vijay Rayapati

    Vijay Rayapati, CEO of cloud management platform company Botmetric, identifies himself as a technology entrepreneur, passionate about creating products, building high-performance teams, and solutions that solve real-world business issues. Vijay is a popular speaker in India and the US, and has co-authored a popular book, “Learning Big Data.” Connect with him on LinkedIn and Twitter.

  • VMware Cloud on AWS Will Bring DevOps Issues to a Head

    VMware Cloud on AWS Will Bring DevOps Issues to a Head

    Now that instances of VMware are starting to become available on Amazon Web Services (AWS), a DevOps ecosystem is starting to emerge around the management of applications workloads moving into and out of AWS.

    Among the more than 4,500 applications that VMware claims already support VMware Cloud on AWS are those from Blue Medora, CA Technologies, Chef, Cloudbees, Dynatrace, Jfrog, Puppet, SaltStack and the Ansible arm of Red Hat.

    VMware CEO Pat Gelsinger told attendees at the recent VMworld 2017 conference that VMware and AWS are just now scratching the surface of what they plan to accomplish together. AWS CEO Andy Jassy added that, unlike other alliances, which consisted mainly of marketing, engineers at both companies are working closely together to deliver VMware globally across all AWS availability zones. At present, VMware Cloud on AWS is available in the AWS availability zone hosted in Portland, Oregon. The service soon will be extended to the east coast of the United States, followed by rest of the world over the course of 2018.

    The availability of VMware Cloud on AWS should force several DevOps issues within enterprise IT organizations that have deployed the VMware stack of software mainly on-premises. Many of those organizations have also been employing public clouds such as AWS. But because those environments are based on different hypervisors, it was never easy to migrate workloads between the two platforms. There are plenty of options for running VMware software in the cloud, but because AWS is the largest provider of public cloud services, there are many customers who want to seamlessly move workloads between their on-premises IT environments and AWS via a common stack of VMware software.

    In many organizations the desire to shift applications workloads into AWS will bring many DevOps issues to a head, as VMware and AWS use has occurred in independently of each other. There could be many workloads running on each platform, but for all intents and purposes, IT organizations have managed both platforms in isolation. Now that VMware is becoming available on AWS, all the challenges associated with moving workloads between a public and private cloud come to the fore.

    Most of those DevOps issues will be focused first on moving some classes of workloads running on VMware into AWS. Application workloads that don’t need to run constantly will be among the primary candidates followed by a slew of data protection applications that will enable IT organizations to back up and archive massive amounts of data inexpensively. Next up will be applications that need to be distributed globally to increase availability.

    At the same time, a lot of VMware shops will be moving application development into the cloud. But just because an application is developed in the cloud doesn’t mean it will stay there. Many IT organizations have already discovered that when it comes to long-running applications, the total cost of deploying them on-premises is less than deploying them on a public cloud. The DevOps tasks ahead, of course, will start with figuring out which VMware-based applications make the best candidates from a financial and availability perspective to be deployed on AWS.

    — Mike Vizard

  • Today’s DNS: DevOps’ New Best Friend

    Today’s DNS: DevOps’ New Best Friend

    Continuous development and deployment is a primary focus of DevOps teams. As part of this process, DevOps teams also require the automatic creation or removal of networks, and automated deployment to production. Automation is a closer guarantee that the process will be done right the first time because the fewer the number of manual steps involved, the less likelihood for human error. Intelligent DNS improves DevOps project life cycles by integrating DNS tasks into your software development and automation tools.

    DNS Needs an Upgrade

    The internet has come a long way since its humble beginnings, from the Advanced Research Projects Agency Network (ARPANET) of the 1960s to an entity that is mission-critical for the world’s commerce. This system is now tested and taxed in ways that were not even conceived of when it was originally designed. One of these early elements, DNS, is now a potential bottleneck for network performance in general and DevOps teams in particular.

    One of the benefits of cloud computing is that it enables DevOps teams to automatically create and remove servers as needed for development and testing. Infrastructure as code (IaC) enables cloud computing to build infrastructure automatically using robust APIs that build servers and add applications as needed. Traditional DNS, with its mostly manual management, becomes a bottleneck for this automated rapid configuration of infrastructure. This is why organizations need an intelligent DNS solution. Intelligent DNS with a robust API can seamlessly interface with current DevOps software, removing the bottleneck that traditional DNS can become.

    Extending Agile with DevOps

    The underlying ideas of agile programming are extended with DevOps. Rather than the traditional way of producing and testing the code, then tossing it over the wall to the network operations team to deploy, DevOps merges the development, testing and operations responsibilities. In short, DevOps should have the ability to break the silos within your IT environment and among the development, QA and operations teams.

    DevOps’ blend of cultural philosophies, practices and tools increases an organization’s ability to deliver applications and services at high velocity. DevOps allows organizations to evolve and improve products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

    Rapid Change Propagation is Essential

    In addition to rapidly delivering applications and services, a goal of DevOps continuous release is to remove bottlenecks to the development, testing, and deployment cycles. This is aimed at creating an environment where the work isn’t hampered with computer delays and frustrations.

    When you’re automating the creation or deletion of 100 virtual servers with a single mouse click using IaC, waiting for 30 minutes to see if DNS changes appear at the edge servers delays your project. Your DNS needs to move as fast as your IaC software and service discovery processes. At this point, intelligent DNS with rapid change propagation becomes essential. When choosing DNS vendors to support your DevOps environment, make sure to include speed testing for the network’s propagation for changes.

    Where IaC Comes In

    The aim of DevOps professionals is to create and sustain server environments that closely resembles the way software developers build and maintain application source code. IaC is the way DevOps teams make that happen.

    IaC is based on three primary constituents:

    • Unit/Integration Testing – Lets you validate your infrastructure code within various phases of the DevOps pipeline and lets you feel confident about what you are pushing to production.
    • Infrastructure Blueprints – Supports the reusable, consistent and rapid deployment part of IaC.
    • Version Control – Facilitates the method track and rollback changes to your infrastructure as needed.

    Infrastructure blueprints can be created using configuration as code (CaC). Using tools such as Terraform, Ansible and Chef allows DevOps teams to build these blueprints by enabling a declarative way of handling infrastructure configuration. Infrastructure blueprints should always go hand in hand with unit/integration testing. Having a robust, API-driven DNS network to couple the full automation of DNS changes alongside the infrastructure and configuration changes ensures a smoother process.

    IaC is next-generation technology for DevOps environments. When combined with CaC products, it changes the way software is built and delivered. Continuous integration and continuous deployment are a large part of the DevOps world that all still depends on DNS technology to connect everything on the network.

    The Role of Service Discovery

    Service discovery is needed to enable your apps or servers to identify which services are available on the network and which IP addresses and ports are associated with them. Previous methods of tracking this information no longer work in the DevOps age.

    Since modern infrastructure is so scalable and changes so quickly, keeping track of service information inside a periodically updated database doesn’t work anymore. Instead, you have to be able to discover services in real time and update your service information continually. Three common service discovery tools are: Consul, Apache Zookeeper and Etcd (with Registrator and confd).

    A tight integration with your managed DNS provider as part of your overall strategy means that service discovery can work hand in hand with the DNS configuration so both systems remain in sync.

    Moving Toward Intelligent DNS

    DevOps needs the same types of robust features you would want for your external internet traffic: end user-facing DNS. You should align with a vendor that can provide the flexibility, agility and reliability you require to deliver your applications.

    Look for features including:

    • Zone Transfers allowed and easily facilitated
    • An anycast DNS network
    • A robust API to support automation, IaC, service discovery and other architecture and tool needs
    • Native integration with common DevOps tools such as Terraform, Ansible and Chef
    • An SLA that meets your needs for reliability and performance

    These elements are necessary, but a more important item on your checklist needs to be redundancy in all layers of the stack, including DNS. Because no vendor is completely bulletproof, use at least two authoritative DNS providers to set up redundancy. Following these guidelines will improve your DevOps’ life cycle by using intelligent DNS.

    About the Author / Kimberly Lacerte

    Kimberly Lacerte has 14 years of experience in computer and technical writing. She is currently the Content Marketing Manager at NS1 in Bedford, N.H. Previously, she has written for Veritas, Symantec, Health Dialog and Dyn. Kimberly holds an English BA from UNH and an MBA from Southern NH University.

  • 10 Ways to Make Outage Mitigation Fun

    10 Ways to Make Outage Mitigation Fun

    It’s 3:47 a.m. You and the rest of the Ops team have been summoned from your peaceful slumber to mitigate an application delivery outage. As you catch up on the frantic emails, Slack chats and text messages from everyone on your international sales team (Every. Single. One.), your mind races as you switch to problem-solving mode. It’s time to start thinking about how to make this mitigation FUN!

    1. Gently remind everyone that the SaaS-delivered automated application delivery strategy you proposed would have prevented this. No need to rub it in, but … if you had turned on a software-defined application delivery platform for your hybrid infrastructure, you’d all be sound asleep right now. Automated real-time delivery decisions and failover would be nice, right? Just sayin’.
    2. Drop a generationally divisive Giphy in the emergency Slack channel. Your coworkers’ opinions on gaming consoles, Spiderman movies and music are different than yours! The perfect animated GIF will remind them of your erudite tastes, while you have their attention. Extra credit if you can work in some low-key shade about not listening to your equally sophisticated opinions on optimized outage mitigation.
    3. Hold an impromptu cloud health dashboard page customization contest. Oh hey, look at that! Your cloud provider’s health dashboard page says everything is fine … because it’s powered by the services that went down. Help your team vent their creative energy (and frustration) with some fun customized MS Paint updates to the offending page. Bonus points for art that reminds everyone of the value of a multi-cloud strategy powered by a programmable application delivery platform.
    4. Use health metrics to cure ills instead of just conducting another really good post-mortem. Tired of “learning lessons” from these emergency room drills? You depend on NGINX for your LLB, but don’t have a way to use those LLB health metrics and data to automate global delivery. Disjointed delivery intelligence means you don’t know how your apps will land with users. You need an end-user-centric approach to app delivery that automates the best delivery path and ensures failover is in place at all times. Micro-outages often fly under your passive monitoring radar, but that doesn’t mean your users don’t notice them. An active, integrated app delivery approach re-routes automatically before you lose business. Post-mortems are fun … but so is making sure your apps survive the last mile. Arguably more so?
    5. Open (and then close) some tickets for the sales team. “Sales needs to sell more stuff.” You’ll feel better.
    6. Build a countdown clock for when you can finally replace your old ADC hardware. Sure, your Mode1 ADC hardware was a sunk cost so you’re stuck with them for a while. But you’re one unnecessary emergency closer to having a fully software-defined application delivery platform for your hybrid cloud. And now you’re even closer. And closer … Tick. Tock.
    7. Leverage real user measurements (RUM) to foresee and fix problems before they happen. Probably best to do this during normal work hours. User experience data from around the world can detect degrading, sluggish resources in real time and user-centric app delivery logic powered by RUM can make quick rerouting decisions automatically. No more getting woken up after the application crashes. While you’re wishing you had RUM on your side, you can look up some fun facts from the countries experiencing app outages. Did you know Luxembourgish is an official language?
    8. Send an email. You, too, can be the weird colleague who sends emails with crazy, middle-of-the-night time stamps.
    9. Do some virtual window shopping. Browse around to see what you could have purchased with the money you were just forced to spend on unplanned cloud instance provisioning to keep your app running. That desktop Nerf missile launcher (or 700 of them) would have been pretty nice.
    10. Swear off the game of chance. You’ve just proven it’s not that much fun after all. Don’t just dump everything onto one cloud and call it done. Clouds go down for so many reasons. Use an application delivery platform control layer to build in the capability to auto-switch to an available resource, while you sleep soundly. Running on multi-cloud without an abstracted control layer removes most of the value of the cloud. Swear off the game of chance. Out loud. Right now.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services and Microsoft. Connect with him on LinkedIn.

     

     

     

  • DevOps Chat: DevOps and the Road to Cloud with JT Giri, CEO, nClouds

    DevOps Chat: DevOps and the Road to Cloud with JT Giri, CEO, nClouds

    For many of us in the IT industry, migrating to the cloud is old news. Even the concept of how DevOps can help on the road to the cloud is not a novel idea. However, we need to remember that while many organizations have some cloud-based infrastructure, the real migration to the cloud is still ahead of us. By the same token, while DevOps is more popular than ever, the percentage of organizations that have fully adopted DevOps is still small.

    My talk with JT Giri, CEO and co-founder of nClouds, dives into this truth and how companies like nClouds are helping organizations big and small to make the move. As usual, the streaming audio of our conversation is below, followed by the transcript of our chat.

    Audio

    Transcript

    Alan Shimel: Hello, everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s DevOps Chat guest is JT Giri, CEO of nClouds. JT, welcome to DevOps Chat.

    JT Giri: Hey Alan, great to be here. Thank you.

    Shimel: Thank you. Thank you for being here. So JT, let’s start off a little bit about – before we get to nClouds, let’s start off – I don’t know if everyone in our audience has heard of JT Giri and your background. So why don’t we go there first, so you can give us a little background.

    Giri: Absolutely. I spent the last ten years doing DevOps consulting before it was called DevOps – so helping companies to streamline their operation and managing complex infrastructure and helping them to put processes in place. My end goal was always to make sure the customer could focus on their end goal, like delivering greater value to their clients. So that’s what I’ve been doing the last 10 years. 

    Shimel: Got it. And then you founded nClouds. When was nClouds founded?

    Giri: Yeah, so it was kind of a transition from consulting to founding this company with the mission of helping companies with cloud adoption and helping them to manage modern infrastructures that would integrate continuous delivery, continuous integration, building better culture. So we transitioned from consulting to a company.

    Shimel: And you know what? You’ve done it and congratulations. I’ve done it now several times. And it’s scary, right? It can be a little scary when you – you know, it’s a big responsibility, but ultimately that’s what makes an entrepreneur, right?

    Giri: Yeah, absolutely. And I think at some point you realize you can add far more value to your clients if you grow it as a team, especially 24/7 support. One of the DevOps principles is to take ownership, right? So we wanted to provide that to our customers and every gig we do, we make sure we are there for them. You know, we provide 24/7 support and make sure we are responsible for their infrastructure. It’s just simply very hard to do it yourself, you know? So that’s why we transitioned into a company and it’s been great. We’ve done over 100 AWS implementations and the transformation for our clients has been amazing. Before where it used to take them three months to deploy code, now they can deploy everyday. So it’s just been an amazing journey. 

    Shimel: Yeah, it has. And I mean, you know, again, as an entrepreneur and you having done this too, JT, it’s nice to get some recognition beyond – I mean other recognition is putting the money in the bank and growing the business, right? But it’s also nice to get awards, kudos or some industry recognition that things are moving in the right direction or the arrow is pointing up, as they say in football. And JT, recently nClouds received some recognition like that, didn’t they?

    Giri: Yes. Yeah, so we’ve been nominated in the 20 most promising DevOps providers of 2017 and as I was saying, it’s really exciting for us, because we’ve been doing great things for our clients and the transformation has been amazing, where now the customer can focus on delivering value to their clients faster. You know, we help them with cloud migration and streamline their operations. So it feels good to be recognized, definitely. [Note from Editor: Just after our interview, nClouds was named to CIOReview’s 20 Most Promising DevOps Solution Providers – 2017.]

    Shimel: Got it. And JT, you know, nClouds is working pretty closely with Amazon AWS, isn’t it?

    Giri: Yes, we are an Advanced AWS consulting partner. We’re also an AWS Managed Service provider and DevOps competency partner.

    Shimel: Got it. And how is that, JT? Because again, for our folks out in the audience, I’m sure many of our listeners are actually working on AWS-hosted infrastructure right now. But you know, from my experience anyway, there’s people who work directly with AWS and they muddle through it. They may get some training and maybe they’re old hat at it. And then there’s a large segment of I think the industry and of the customer base who really, they need the nClouds of the world. They need AWS expertise to help them make it happen. And I’ve got to assume that that forms a good chunk of your customer base right now, yeah?

    Giri: Yeah, absolutely. So Alan, you know, you’re in the space and you know how confusing things are right now. You know, there’s people already moving to server-less and there’s Kubernetes, Nomad, and you know, there’s like five or six container schedulers … They want to be like Amazon or Netflix or Google of the world, but it’s very hard to get there. Since we’ve done this so many times, we have experience working with the client and taking one step at a time. Because if you’re starting out it can be intimidating, because you don’t know – you have a good vision and you want to release code fast and you want to make sure you can innovate fast. You want to migrate to AWS, but it’s very, very tough. And Alan, when we speak with customers, some of them are still starting with the config management conversations, right?

    Shimel: Mm-hmm.

    Giri: And so we have to kind of tone it down for them. For them, the next step is, “Hey, let’s figure out – maybe we need to work on implementing some kind of config management for you before we even think about micro services,” right? So that’s when someone like us can come in and help you to understand, where can we get the biggest bang for the buck? What should be the next step? And really help you pave the way to go to this transformation with a DevOps path.

    Shimel: Yep, agreed. So JT, you know, when we start talk about it though – I want to turn back – you actually wrote an article back in May that was up on devopsy.kinsta.cloud about why your company needs an automated infrastructure now. And when you were talking it kind of triggered that for me. For our listeners out there, why do their companies need an automated infrastructure right now?

    Giri: So if you subscribe to lean thinking, anything that doesn’t add value to your customer is a waste, right? So you need to define your work rigorously to be used that way. With automated infrastructure you can actually facilitate that. You can scale up and down based on your customer needs. And then you can focus on adding value to your customer and you can also lower the cost, where you just scale based on the client’s needs – and all this can yield better reliability. You know, the customers will be happy. If you’re not leveraging automation and if you’re treating the cloud infrastructure like on-prem, then you’re not really getting any value out of the cloud. So that’s why I wrote that article, just illustrating that you have to focus on automation and the cloud so you can lower the cost, have efficient workflow, and in return deliver better reliability and better customer experiences.

    Shimel: Excellent, excellent. So you know, JT, you and I and people like us, we’re living in a DevOps bubble. We think DevOps is great. We think this type of methodology, this way of thinking, this kind of cultural organization is a no-brainer and of course it has to make things better. But there are a lot of people who maybe haven’t drunk the Kool-Aid, or they just don’t see it. And they’re saying, “Okay, that’s cool. That’s this week’s buzzword. What’s next? How do we keep this going?” Where do you see this going, JT? And when I say this, I mean this whole sort of – I call it Agile IT, because I heard someone at Gartner use the term. But DevOps, Agile, this new way of doing things – where do you see it going

    Giri: Yeah, so I think we have a long way to go, Alan. As I mentioned earlier, you know, we are in the Valley and we are drinking this DevOps Kool-Aid. And because we have experienced this, right? Like I’ve done a lot of DevOps transformations and I can see before and after and it’s just amazing when you get the results. But there are a lot of companies out there, as I was mentioning earlier – they’re still beginning to think about config management systems, right? And they’re still doing config management in Pearl. And another challenge I face, especially when we’re working with enterprises, people have gotten used to doing things a certain way and all of a sudden there’s like so many better ways to manage your infrastructure.

    So Alan, I think we have a long way to go and I think when people feel like, “Oh, this is just a buzz,” what we try to do with companies is take small steps, right? If they’re still working on config management, try to implement that and show them metrics on how things were before the implementation.

    Shimel: So JT, what about nClouds? What’s next with nClouds? I know recently you guys have added some talent there and you’ve got this award going on and you’re getting buzz in the industry. Where do you see the company going?

    Giri: Yeah, so our mission from day one has been to drive this cloud adoption and help companies with DevOps transformation. So companies like Google or Netflix, the unicorns, they can really attract a lot of DevOps talent. But there are a lot of companies and a lot of enterprises out there and they’re not able to attract that kind of talent. So our mission is to bring DevOps transformation to all of these companies, right? That’s why we’ve been hiring. And Randy Newell joined recently, so we’re very excited about that, and we have been hiring very talented engineers.

    And we also released a product called nOps.io, which manages security and change management of the cloud. So over the last several years the focus has been a lot on infrastructure tooling, like Terraform and (AWS) CloudFormation. And I think we’re missing the process piece of the puzzle in this DevOps. So that’s what we’re trying to bridge, where if there’s a hundred people or ten people making changes in your infrastructure, how do you manage those changes? How do you make sure security is not an afterthought? How do you make sure every single change is documented and traced without slowing people down? So we’ll continue to innovate and help companies in the DevOps space, yes.

    Shimel: Got it, got it. All right, well JT, we’re about out of time here. Thanks for coming up and appearing on this episode of DevOps Chat. Continued success with nClouds. And we’d like to see more articles from you up on devopsy.kinsta.cloud, actually. I’m sure our audience – our audience really liked the first one, and we’d like to see a lot more.

    Giri: Thanks, Alan. Thanks for having me.

    Shimel: But good luck. Thank you. All right. Hey, JT Giri of nClouds – CEO and founder of nClouds, thanks for being this episode’s guest on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We’ll see you on the next episode of DevOps Chat.

    — Alan Shimel

  • Cloud Capabilities Turn Developers into Operational Experts

    Cloud Capabilities Turn Developers into Operational Experts

    The upside-down world of digital transformation can leave you feeling like you’ve fallen down an internet rabbit hole. If you’re a DevOps denizen, the swirling pace and scale of virtualization might give you that “lost in the Technicolor forest” feeling when it’s time to release an app into the wild. “Curiouser and curiouser!” you say as you try to sort through hybrid combinations of private and public clouds, CDNs, and data centers.

    As a developer, you worked hard on the design, build and test—now you want to make sure it takes the best, fastest path to microservices and users. It’s folly to trust the answer from any one source—synthetic measurements may purr like a Cheshire Cat over hardware health, meanwhile the White Rabbit of RUM (real user measurements) is spazzing out over latency and traffic jams. The lesson Alice finally learns in Lewis’ timeless tale? She must learn to control the journey herself.

    Developing for the Complex Cloud

    Fortunately, there’s a way for developers to mix that “just right” solution that will reveal the right path through the internet forest. This used to be the purview of operations—setting up servers and delivery conduits. In the pre-cloud era, developers just wrote code. Somebody in Ops pushed it live, and that part of the process was opaque to the developer. With the proliferation and maturation of the cloud, the Ops team is increasingly focused on dynamic infrastructure and services. Developers routinely spin up their own servers. As DevOps teams focus more on microservices and containers and less on “stacking and racking” servers, performance, control and delivery become the focus areas that matter.

    As the division between Dev and Ops experts continues to dissolve, each becomes increasingly aware of the other’s roles, responsibilities and skill sets. The goals of agile development, non-stop testing and optimized delivery become the shared destination; paths merge until everyone is creating momentum around the prized feedback loop. As infrastructure and services become more abstracted, the focus is less on writing original code and building stacks and more on selecting resources. The selection and use of these resources has to be strategically guided by real-time intelligence to meet multiple performance and business objectives. The more abstract and hybridized the infrastructure becomes—and it is moving rapidly in that direction for every business—the harder it is to navigate. If you can’t keep all your resources straight, you can’t optimize them. Centralizing and automating tracking and traffic management is mission-critical.

    The Delivery is in the Code

    Which brings us back to the developer’s mandate to control and optimize delivery from the application. Cloud-based delivery tools combine real-time user measurement with scriptable application traffic shaping and built-in cost controls. Gone are the days of blaming poor performance on the network. End users expect seamless, instantaneous experiences, no matter what. This is a tall order for modern apps that combine video, microservices and dynamic content. To ensure high quality of experience (QoE), you have to automate and optimize with software-defined delivery. Developers can now contribute to optimization by coding in delivery intelligence.

    This isn’t merely another task for the developer; it’s an opportunity. Developers are now empowered to deliver the functionality of their product or service exactly as designed. Developers are now actively part of the process that brings together global and local traffic management data (RUM and infrastructure health), application performance management and cost considerations to ensure the cheapest, fastest path to that microservice. The balance and mix of these factors can be customized and fine-tuned by the developer (a.k.a., the newly minted operations expert).

    The Bleeding Edge Becomes the Bedrock

    You know the cloud is no fairy tale when 74 percent of tech CFOs claim that this year the most measurable impact on their business will come directly from cloud computing. Spending on cloud computing is set to grow at 19 percent CAGR through 2020, six times the rate of overall IT spending. Developers who can harness the magic of hybrid cloud/CDN for video, web content and application delivery will be rock stars. Picture it: fully automated delivery based on business rules, actionable data from real user and synthetic testing, and self-healing network optimizations. Developers can push their capabilities and control right to the bleeding edge, making them an even more agile contributor to the continuous improvement cycle.

    Soon enough, as technology progresses and infrastructure is increasingly software-defined, these skills will become a requirement. Over the next few years, this data-driven approach to app and content delivery will be considered a standard capability for digital businesses and a core responsibility for developers. The forward momentum of organizations that have committed to both cloud-first and DevOps-first strategies is powerful and will quickly boost early adopting competitors out of reach. The number of developer-operators capable of managing application delivery in capacity-aware, consumer-responsive, application-tuned ways will soon build to critical mass. Don’t get left behind, wandering lost in the woods.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services, and Microsoft. Connect with him on LinkedIn.