devopsy.kinsta.cloud

Tag: Automic

  • DevOps Chats: Automic + CA + Broadcom, a Release Automation Journey

    DevOps Chats: Automic + CA + Broadcom, a Release Automation Journey

    The life of an acquired company can be an exciting one full of unexpected twists and turns, and that’s been true of Automic software. Scott Willson, a repeat podcast guest and longstanding member of the DevOps community, joins us again on DevOps Chats. He describes his acquisition journey as being akin to a “barracuda, eaten by a great white shark, eaten by a whale.” Scott is product marketing director, Release Automation at CA Technologies, a Broadcom company (the new proper name for Automic + CA + Broadcom).

    Scott shares what it’s like being a software DevOps company inside Broadcom, whose strong roots come from the chip manufacturing business. While software has its many differences from chips, of course, Scott shares how many of the DevOps principles and heritage from lean manufacturing have made the transition easier. There are valuable lessons here for all of us.

    Amid all the change, Automic shifted its products to the freemium model. Automic Continuous Delivery Director is now free to use for up to 10 active releases. We talk about the upcoming releases, which includes machine learning. Join us as we bob and weave through the acquisition story into the world of continuous automated delivery.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chats podcast. Today, I’m joined by Scott Willson, he’s product marketing manager, Release Automation at CA Technologies at Broadcom—that’s a mouthful. I think we’re gonna explore a little bit of that.

    So, our topic today is really catching up with what’s been happening with the Automic product and CA’s, this part of the acquisition back into Broadcom and just kinda catch up with Scott. So, he’s been on the podcast before. Scott, welcome to DevOps Chats.

    Scott Willson: Thank you, Mitch. Glad to be here.

    Ashley: Appreciate you being here. Would you start just by introducing yourself for any of our audience that doesn’t know you, a little bit about what you do, and tell us a little bit about CA Technologies at Broadcom.

    Willson: Yes, yes, so my name is Scott Willson—two Ls in Willson. I think many listeners may know me. I have been, in the past, an author with some of Gene Kim’s DevOps Forum papers, and I’ve been at the DevOps Enterprise Summit several times. I’ve been fairly active on blogs and all that stuff.

    And where my kinda claim to fame was, I came from a company called Automic. That’s spelled Auto-mic for the phonetic spelling of it. My background is, just to throw this in here, too, my journey, as I always tell people, is I started from a development standpoint writing the code, migrated my career kinda doing the DevOps thing before anyone called it DevOps, like many others.

    Ashley: Mm-hmm.

    Willson: And yadda yadda yadda, here I am now with a software company speaking all things DevOps and trying to help people get better at releasing their software.

    Ashley: You’ve certainly been a part of the community for some time now, so we appreciate all your contributions. Well, you’ve been through quite a journey. I know being acquired by CA and then CA being acquired by Broadcom—why don’t you kinda catch us up? Maybe tell us a little bit about that journey. I think you described it as an 18 month history going through that.

    Willson: [Laughter]

    Ashley: You know, we don’t have too long on the podcast, [Laughter] but if you can kinda give us a little bit of that path that you’ve been on.

    Willson: Yeah, yeah. You know, I kinda looked at it like a, it was almost like a barracuda eating a great white who was eaten by a whale, right?

    Ashley: [Laughter]

    Willson: It was a really interesting, very quick journey. It was a couple years ago when I was with Automic Software. We were acquired by CA Technologies, and about a year or 18 months after that acquisition or so, Broadcom bought CA Technologies to the—not just our surprise, but of course, to the surprise of the entire market.

    Ashley: Mm-hmm, yeah, it was.

    Willson: There was a lot of press about it.

    Ashley: It was a surprise.

    Willson: And so, yeah, it was a very, very quick and interesting turnaround. We are now known as CA Technologies, a Broadcom company. As far as Automic goes, we are retaining the Automic brand, so you’ll see a lot of our old software and all that will have the Automic brand. And not just Automic, but our current leadership has really felt to really keep and embrace the brands that we’ve had. So, you know, Blaze—CT is still gonna be Blaze, and Rally is gonna be Rally, those type of things.

    Ashley: Mm-hmm.

    Willson: So, the brands are remaining, which I think is useful, because even though CA had remained Rally—I know I, anyways, always refer to it as Rally, because—

    Ashley: I do, too, yep. [Laughter]

    Willson: – right, because that’s what I always knew it as. [Laughter]

    Ashley: Especially knowing them from the beginning, it’s hard not to call them Rally, but yes.

    Willson: Right, exactly. So, Automic is still going to be Automic from a product brand positioning. And then from a company standpoint—yeah, we’re still CA, just a Broadcom company. Within Broadcom, our group is known as the Enterprise Software Division, so we are a distinct division within Broadcom.

    Ashley: Mm-hmm.

    Willson: And then, to add to that, to the little journey, what has been interesting to me is—I remember it was a year ago, the last Forum meeting I was going to or what many of us in the inside called those meetings, the Gene Kim’s Great Slumber Party.

    Ashley: [Laughter]

    Willson: Right? We kinda talked about being lean, and some of the people, I remember having discussions with and running papers, we just really got to talking about what it means to run lean and the lean manufacturing and the whole thing, right, that DevOps is based on and that The DevOps Handbook espouses and all these kinda things.

    And after that, right, three months after that meeting it was announced Broadcom was gonna buy us and then they actually did, and here I am all this time later. And I bring that up because what was interesting to me, Mitch, is that Broadcom embodies this. They run lean.

    Ashley: Mm-hmm.

    Willson: And it’s been an interesting journey to go from the short time at CA, which ran big, to now being with Broadcom, which runs lean. And they run even leaner than what Automic did, which was in ISV, right? You know, Independent Software Venture.

    Ashley: I was curious about that, because I know Broadcom, you know, I had worked with them as a chip supplier with companies like Broadcom ad Qualcomm and, you know, manufacturers of chips in telecommunications think about the world, they’re much more, you know, operational efficient. It’s all about fractions of pennies and the cost of their goods to maintain profitability, but that’s super high volume. So, it’s a different mentality than a software company.

    Willson: It is, and there are some significant differences, I suppose, from the business or sales aspects. But from a production aspect, there really wasn’t a whole lot of difference. When you think about taking a product to market, right? Now, we were doing this with software, they’ve done it with chips, but Broadcom is an engineering excellence company. They really pride themselves on having the best of fill in the blank of engineering, whether it’s engineering processes, engineering whatever. In fact, what has been interesting post acquisition is that our engineering staff for the bulk of our products have actually increased. Broadcom is very keen on ensuring that the products we deliver are best in class.

    Ashley: Mm-hmm.

    Willson: And so, they realized a way to do that in the market is to make sure they’ve got the top minds developing and producing and shipping these products, right?

    Ashley: That has to be refreshing to you—you and the team.

    Willson: Oh, yeah. It was very interesting to see that that was the case. It’s been a unique acquisition as far as that goes, and to see that—no, they wanted to increase the head count of R&D. [Laughter] It’s important for them.

    Ashley: Mm-hmm. What? [Laughter]

    Willson: Exactly. Like—wait, what? They want the products to improve, to get better, and to continue to be viable and market leading. And so, they embody the lean processes to do all of this stuff. And so, it’s been—there’s a little bit of a learning curve, I think, on both sides to adapt to this new way, but here we are. You name the things that are automated—I mean, Broadcom automates just about anything and everything. The very stuff you read about, Gene Kim talks about in his book, saying—and even in Nicole Forsgren’s book, Accelerate, you know, automation is at the key of a lot of these things, and Broadcom embodies that.

    Ashley: It is. It’s a much different kind of company. If you’re not a hardware person or haven’t worked at a chip company, what I said, it’s—fractions of a penny make a difference in cost, and that cost can be in materials, but it also can be in process. And when you multiply that by millions upon millions of chips that they may ship a particular line, that’s a lot of money. So, it makes a huge difference in the profitability of the company—

    Willson: That’s right.

    Ashley: – to be able to reinvest and give you more engineers to be part of your team.

    Willson: That’s right. And so, software is a little different, right? It’s not the pennies like that. Obviously, with software, the margins are different, because you’re not dealing with a physical thing, a commodity, right? But the principles to be efficient like that are absolutely espoused by DevOps. And one of the things that this transformation internally has occurred—because we’re transforming ourselves from a software company, right? I think we’ve made some press releases talking about our BizOps platform, a holistic platform—

    Ashley: Right.

    Willson: – that we’re offering the market. No longer should you be thinking of us like the CA of old where you had a bunch of different siloed tools. Now, they’re all coming together in a holistic way to provide real business value and create a true, interesting platform for everybody.

    Ashley: Mm-hmm.

    Willson: But just this way of doing things lean like that and embracing the agile way of turning things around has been a cool thing to behold.

    Ashley: That has to be really good, because I haven’t talked with somebody that’s had that experience—not that others haven’t, but to have that common lexicon frame of reference of thinking about producing software like a software factory just like a hardware based factory. You have a lot of synergies and commonalities there. Yeah, there’s differences, too, but instead of software being this mystery to hardware guys or vice versa, right, you can talk and work together and understand the efficiencies, improvements, speed, impact, quality—all the things that drives the manufacturing company also drives software.

    Willson: That’s right. And what’s been exciting, too, with this opportunity to change—really, the Broadcom offer has provided us an opportunity to change things and to really force these integrations and synergies between what used to be separate divisions of CA but are now different teams and the interoperability that’s happening between them to deliver this BizOps platform is really exciting. It’s cool to see that now it’s like—look, we have all these things, but what’s the point, unless we’re focusing on business outcomes, right?

    Ashley: Right.

    Willson: We can actually drive a business outcome if there’s harmony and cohesiveness between all these things, and that’s very exciting. In fact, one of the other things along these same lines that was announced is the free tier program—I don’t know if you see the PR a couple weeks ago, Mitch—

    Ashley: I did.

    Willson: – but now, a lot of our products are offered for free.

    Ashley: Yeah.

    Willson: So, for example, a continuous delivery director, or Automic Continuous Delivery Director, if you go to CDDirector.io, you can just use it for free, up to 10 active releases. And Rally has some free tier as well. So, basically, we’re now offering the freemium versions of what we had, and—

    Ashley: Have the products changed substantially to be able to do that? Are they less functional or are they time based or just volume, kinda getting folks to up to date?

    Willson: It’s really just volume, right? Yeah. They haven’t really—well, a lot of them didn’t really need the change. A lot of the products that are offering this are the ones that are already SaaS based already. There will be more that are coming, of course, as things are being migrated to be SaaS based, and that effort is under way.

    But an example of Automic Continuous Delivery Director, there’s not really a time limit. It’s 10—10 active releases. That’s a lot of releases.

    Ashley: Mm-hmm.

    Willson: And you can just use it, and use it at will for that. You wanna get more than that or grow it across the enterprise or make it the standard or something, same with the Rally and Blaze CT. Oh, well, yeah, then you can buy the licenses that let you use it more broadly, right?

    Ashley: Mm-hmm. That’s a great model. I mean, I think we’ve sort of disproven the crippleware approach. Nobody likes that.

    Willson: [Cross talk], yeah.

    Ashley: Exactly, and being able to use it on enough of software production; you talked about 10. You’ve gotta be able to get a pretty good feel for what the product does that’s gonna do what you want it to do and start to integrate it into your tool chain workflow platform.

    Willson: Right, and these are 10 active releases. In other words, 10 releases in parallel, right?

    Ashley: Mm-hmm.

    Willson: Well, that’s—like you said, you should really be able to get a feel for it.

    Ashley: Yeah.

    Willson: Being able to run that many releases in parallel to each other.

    Ashley: Well, that’s awesome. That’s great to hear. I’m excited to hear about more of that coming from you, too.

    Do you have a new release coming up, here?

    Willson: Yeah. So, speaking along those lines, we have a new release for Automic Continuous Delivery Director. We’re pretty excited about this release. It is our first release that includes some ML capabilities and heuristics that are involved. Basically, what we were looking to do with this is, amongst other improvements and advances we made in the product, right, to help with continuous delivery, one of the things we looked at is that there’s significant bottleneck in continuous delivery, the methodology, which is QA or testing.

    Ashley: Mm-hmm.

    Willson: Now, as you probably know, Mitch, continuous testing is technically a subset or a component of continuous delivery.

    Ashley: Right.

    Willson: And I might argue that unless you’re doing continuous delivery, you are not doing continuous delivery.

    Ashley: Right.

    Willson: You need to be doing—

    Ashley: You need to think of continuous delivery is plan, dev, test, deploy, operate, right?

    Willson: That’s right, and you’re testing continuously, right? But the problem is, QA wasn’t really built to be agile themselves. So, they kinda became the bottleneck, not just from the way that they run, but you, as a QA person, right, testers, you build out all these tests. And so, you release this small change per DevOps per agile per continuous delivery, right? And it goes into QA and you run, you know, 1,000, 10,000 tests—and I’m not making these numbers up. Literally, a lot of our large enterprises have thousands and 10,000 tests.

    Ashley: Oh, yeah. Totally.

    Willson: Alright, so then, we’re in the waiting game, right? And maybe it takes however long for the test results to come back and then you get feedback to development. So, we found with our, a lot of our large customers, you know, the Global 2000, that this was a significant bottleneck. So, now what we do, what occurs, is that when you do that release and you’re a pipeline, right, you’re a release pipeline and it gets pushed to QA, one of the things that we do is, we look at several heuristics.

    So, we come around and say, “Alright, well, what are all the tests? What is the historical responses or outputs of the tests?” Right? How many of them failed? Which tests are flaky? How many tests are new tests? We want to actually run these tests first. So, a flaky test, for example, it ought to run at the front, and if it fails—pfft, we’ll send that feedback immediately to development or to QA so that we’re identifying these things earlier, quicker, faster, rather than having to wait on the back end for this, right?

    Ashley: Try to get to that 80/20, right? Get the things—

    Willson: That’s right.

    Ashley: – upfront that are gonna cause the most issues, find the most bugs.

    Willson: Right. So, we’re looking at all the data and intelligently figuring out the tests for you. The other thing that we’ll do is that we’ll look at the code changes you’ve made and we will map those code changes. At least in the case of Java apps, we’ll be able to map the code change to specific test suites.

    Ashley: Mm-hmm.

    Willson: So, now, when you submit that one component change, you are actually getting identified just the test runs that affect or exercise that component. So, altogether, when you put it all together, Mitch, what occurs then—now, when a change gets pushed into your continuous delivery pipeline, when it hits QA, you’re in a position to not have to run all 10,000 tests. You’re in a position now to run the high risk tests, the tests that you have marked are critical and important, right? So, those are included, that’s taken into account, too. And the test that we know actually exercised the change that you put in.

    So, you’re able to run what you have to run to ensure you have a high quality and also order them in such a way where there’s high likelihood of failure that Development is fed back that feedback earlier and faster. And so, we’re very excited about this release.

    Ashley: That’s awesome.

    Willson: Yeah.

    Ashley: Boy, gone are the days, I can remember when I would judge the quality of the release by how severe the bugs are and if we haven’t found really big problems yet, we’re not through. There’s more to come. [Laughter] You know, that was the heuristic. [Laughter]

    Willson: That’s right. Exactly. That was the heuristic.

    Ashley: That’s right. We’re far from those days, aren’t we? [Laughter]

    Willson: Well, you know, because one of the other constraints, if you think about agile and continuous delivery, right—small change and you make more frequent small changes and the “State of DevOps” report just came out, right, a week ago or this week, and it again is showing how this way, this approach is actually reducing the bugs and reducing ________ quality.

    All those things are great. But that now means one of your biggest resource constraints is time. And what we’ve found with our customers, it was time in QA. So, by intelligently assigning the tests on a run with a particular change, we’re able to shorten that down. You’re not having to wait for all 10,000 tests, you’re just waiting for the five that matter to run against that little small change and—pfft, get it shipped out the door.

    Ashley: Exactly, right. Be smart about testing, yeah.

    Willson: That’s right—be smart about testing. Exactly right.

    Ashley: Now, do you have a date when this is going public? Are you in beta now? Where are you at?

    Willson: Yep. So, if you were an on prem user of the product, it is actually GA now. It actually was up on the download site yesterday and—

    Ashley: Oh, nice.

    Willson: – it can be downloaded and you can go through the upgrade process. If you’re on our SaaS platform, you know, October 2nd, it’ll just be online working and available for you in the beauty of SaaS, right?

    Ashley: Nice. Well, great. That’s fantastic. Awesome. Well, congrats on the great release. I hope it works out very well and also the free tier brings some new customers, new people onto your platform and expand that as well.

    We have a few minutes left. I know you’re gonna be at the DevOps Enterprise Summit, correct, in Las Vegas?

    Willson: Yeah, exactly. So, we’ll have a big booth there at the DevOps Enterprise Summit, so certainly looking forward to seeing everybody wearing our Broadcom wear. We’re gonna—not to give away too much, but I think we’re gonna have some pretty cool giveaways at our booth at various times, so, you know, definitely come check us out.

    Ashley: Come early, come often for the swag.

    Willson: What—get the swag? [Laughter] That’s half of what you go for. Especially if you have kids, you know? I see some of these people, they’ve got bags full of this stuff, right?

    Ashley: Mm-hmm.

    Willson: And I’m like—yeah, you’ve got kids at home. [Laughter]

    Ashley: You don’t wear a Small—you don’t wear a Small. What are you—what are you doing, there?

    Willson: [Laughter] Exactly right. Exactly right. But we’ll have some things, a couple of the giveaways we’ll have I don’t think you wanna give to the kids, let’s just say that.

    Ashley: Okay.

    Willson: And if you’re going to the Gartner Symposium, we’re gonna be at the three upcoming Gartner Symposiums in Orlando, São Paulo, and Barcelona as well.

    Ashley: Fantastic.

    Willson: So, yeah.

    Ashley: Well, good. We’re gonna have to check in every six months or so just so we know what swag wear, logo wear to look for you in.

    Willson: [Laughter]

    Ashley: This time it’s in Broadcom—I’m kidding you, of course. But almost—it’s almost true.

    Willson: It’s almost true. Feels true. [Laughter]

    Ashley: Scott, it’s been great having you on the podcast. Appreciate you being here.

    Willson: Thank you so much, Mitch. Appreciate it and look forward to seeing you and Alan at the DevOps Enterprise Summit.

    Ashley: Absolutely. Look forward to it as well, and great to catch up with you about everything happening. Well, I’d like to thank you. I’d like to thank Scott Willson, Product Marketing Manager—or sorry, Product Marketing Director of Release Automation at CA Technologies, a Broadcom company—I think I got that right—

    Willson: You got it right.

    Ashley: – for joining us on the podcast. [Laughter] And thank you—you, our listeners, for being here as well. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chats podcast. Be careful out there.

    — Mitchell Ashley

  • CA Technologies Advances DevOps Automation Agenda

    CA Technologies Advances DevOps Automation Agenda

    CA Technologies further advanced its staged goal of unifying its disparate portfolio of DevOps automation tools by announcing today a new release of CA Workload Automation AE (AutoSys) software now directly integrated with the CA Automic One Automation platform the company acquired early last year.

    CA AutoSys is the older of two offerings and is positioned by CA Technologies as being able to support more complex workloads running on a larger number of platforms, including mainframes. CA Automic One Automation was acquired to bolster the automation capabilities CA can offer optimized for distributed computing environments.

    Gwyn Clay, vice president of product management for CA Automic, said it’s no secret CA Technologies has multiple automation engines. The long-term goal is to enable organizations to employ any mix of automation engines and associated DevOps tools as they see fit to create what the company describes a software factory.

    Other new capabilities being added to CA AutoSys include the ability to centrally manage all the various agents the company provides, support for connecting to Amazon Web Services (AWS) and Azure Database Services, improved load balancing and the ability to set up more custom email notifications.

    Clay noted the rate at which IT organizations are embracing DevOps varies widely. Just about every organization has at least one DevOps project or pilot in place, but most of them are still relatively nascent compared to the level of sophistication being applied by web-scale companies, he said.

    CA Technologies is betting that, rather than stitching together components themselves, enterprise IT organizations will prefer a more modular platform that requires less effort to set up without locking them into a specific tool.

    DevOps is coming to the enterprise in one form or another. But unlike web-scale companies, where developers and engineers have tended to work closely together from the inception of the company, enterprise IT organizations will navigate myriad culture issues. There has been a historic predisposition in enterprise IT organizations for developers to “throw code over the wall” to IT operations, with little regard for how that code might run in the actual production environment. IT operations teams, meanwhile, have not always been as forthcoming about the state of that production environment as they might be. That lack of trust and visibility means both sides often make decisions that are not always in the best interest of the overall organization. For example, an application workload might wind up being deployed on a public cloud, even though that platform may be both more expensive and less secure.

    At the same time, it’s still not clear to what degree warring cultures inside the enterprise will be able to put aside their historic animosities to create a coordinated approach to automation and DevOps. Mainframe and distributed computing teams to this day still battle for control over workloads inside the enterprise. Whatever the outcome, there’s no doubt various teams will eventually be forced to work more closely together to achieve DevOps goals regardless of whether they like it.

    — Mike Vizard

  • CA Technologies Positions Automic at the DevOps Core

    CA Technologies Positions Automic at the DevOps Core

    After acquiring Automic earlier this year, CA Technologies suddenly found itself with an embarrassment of IT automation riches. Now the company is moving forward by further integrating the Automic IT automation platform with the rest of the portfolio of tools and services that it says are required to construct a software factory.

    Ron Gidron, technology evangelist for Automic, says the latest version of Automic increases the number of integrations with the rest of the CA Technologies portfolio to include support for CA Test Data Management, Service Virtualization, Privileged Access Governance, Application Performance Management and Veracode application security software, among others.

    CA Technologies has made it clear it intends to make the release automation software originally developed by Automic the foundation of its overall DevOps strategy. Most of that effort is now focused on integrating the various elements of the CA Technologies portfolio. Longer term, CA Technologies will eventually move to rationalize any duplication in functionality.

    Version 12.1 of Automic also brings forward orchestration tools and self-service capabilities to enable developers to provision resources within guidelines defined by IT. Gidron says that while there will always be a need for IT operations specialists, CA Technologies is making a concerted effort to “shift left” to provide developers with more programmatic control over the IT environment. To facilitate that process, Automic and the rest of CA Technologies have been investing in creating a standard set of external-facing REST APIs, which also will be used to make it easier for products and services created by the company to consume a wide variety of external data and metrics.

    Via acquisitions and internally developed software, CA Technologies is clearly trying to unify application, infrastructure and security management with the context of a single DevOps framework. The company doesn’t plan to force organization to consume that entire stack of software. But it will try to make acquiring as much of its portfolio as financially attractive and frictionless as possible to drive what the company describes as intelligent automation across a modern software factory. Driving that need is the realization that just about every company in every industry is now dependent on some form of custom software to drive one digital process or another.

    The rate at which CA Technologies has been expanding its DevOps portfolio via acquisition is a major contributor to what appears to be a wave of consolidation starting to occur across the DevOps category. Regardless of how advanced any organization might become in terms of building a software factory, major IT vendors realize that it’s only a matter of time before IT organizations start to pressure them to bundle more DevOps-related functionality together. In fact, the line between what’s DevOps today and tomorrow versus what was considered traditional IT management appears to be getting more blurred with each passing day.

    — Mike Vizard

  • Get the Full DevOps Picture with our Continuous Delivery Map

    Get the Full DevOps Picture with our Continuous Delivery Map

    Automation and continuous delivery are shifting from being industry trends to becoming industry standards for fast and effective app deployment. To compete in today’s market, organizations must adopt technologies and applications for more rapid deployment. But with so many tools available, this is incredibly challenging without knowing which specific tools and methodologies are most effective.

    Automic, now part of CA Technologies BU, has been a leader in this space and just launched the “Continuous Delivery Map,” inspired by the London Tube. Designed to be interactive and instructive, this subway-like map helps customers easily visualize and assess the best use cases for continuous delivery tools for their own digital transformation and reduce the confusion for IT professionals.

    Before I get into the specifics though, I wanted to share a few trends I’ve been following that have ultimately led to development of this map. In recent years, we’ve seen an expansion of freeware and open-source offerings for automated tasks within IT. But organizations must consider and address the long-term sustainability of these software products since the cost of adoption could be risky. It may only be useful for two to three years, until community developers move onto the next new thing—leaving orgs with the costly task of rewriting delivery pipelines or automation mechanics every three to five years. This is compounded by the fact that the term “DevOps’ itself has even become a trend”—it’s catchy and grabs attention, so everyone is branding themselves as a DevOps tool, even if it’s not a core use case of a tool. Now, there is increased confusion on what tools are available, what aspect of DevOps they’re most valuable for, how sustainable they are, and what the market thinks about them.

    Over the past few years, I’ve also seen some organizational shifts as well. Starting at the top, I have noticed that CEOs have recognized the competitive advantages of applying DevOps practices, including faster software production, greater revenue gains and better responses to market conditions. Leadership teams are now responding with mandates for DevOps implementations in their own orgs, and C-level hiring and firing decisions are being influenced by their awareness of DevOps. Separately but related, development and operations teams have continued to fundamentally work and solve problems differently, with developers working in a linear fashion, solving problems sequentially and operations working in a circular fashion with frequent interruptions. Automation is the key to making operations agile because it will reduce interrupt-driven processes and practices. An agile operations team will empower true DevOps because Ops members will have time to collaborate and contribute to DevOps practices. Without it DevOps really means DevNoOps.

    Enter the Continuous Delivery Map

    We developed the Continuous Delivery Map to help our customers and the industry at large understand the hundreds of available DevOps tools across several “lines.” We sought to create a centralized, unbiased way for IT professionals’ research and visualize how DevOps fits into customers’ continuous delivery pipelines. After thinking more about patterns that fit a delivery pipeline, we settled on a metro rail system similar to the London Tube or New York Subway. Now, with this map, customers can easily visualize the ‘tooling’ in their continuous delivery process with an understanding of the tools best use cases. You’ll see we have several “lines” from middleware to continuous integration to toolchain orchestration—all with more information on each product in each line.

    As the tool evolves, we hope the map will become a platform that uses data and feedback to rank the tools, capturing a market consensus on best-in-class DevOps tools. Customers will then be able to truly see and choose the best tools in various categories that meet specific continuous delivery needs and strategies.

    — Scott Willson

  • Automic Chart Maps Out Its DevOps Ecosystem

    Automic Chart Maps Out Its DevOps Ecosystem

    Everyone who follows me knows that I’m a fan of XebiaLabs’ Periodic Table of DevOps Tools. It was the first attempt I am aware of to arrange things in a way that helped DevOps teams navigate the increasingly bewildering world of DevOps toolsets. In fact, my friend Colin Walker over at ExtraHop and I have been planning to pick some up for our offices for a year or so.

    (Add on note: It sounds like I’ll be getting a copy of the XebiaLabs poster. Woo hoo!)

    Visit the interactive version.

    So this week when I found out about Automic’s chart—let’s call it “The Spider” because of the way it branches out—I thought I’d let you all know that it is also out there. The cool part about The Spider, in my opinion, is the interactivity (which means I still want the XebiaLabs poster for my office). You can click on a node, get information about the tool and be presented with a link to the tools’ website—and, if they’re integrated with Automic, a link to the integration in their marketplace.

    For quick research, this is a nice chart. I wouldn’t want to have to maintain it, at the rate the market is changing, but it’s a useful starting point for “I need a tool that does X” and exploring short one or two paragraph descriptions of each of the options. It’s not complete, but it would be a full-time job to make such a chart complete and keep it up to date, and it’s pretty far along. You won’t miss any major vendors in a space by starting with The Spider.

    I clicked around and looked at the writeups for several products, and they read well. Considering that Automic is a vendor (they’re owned by CA, so kind of an über-vendor) in the space, it would not have surprised me to find they were limited or slanted in their writeups, but they weren’t. So I asked Scott Wilson, product marketing director for release automation, about that, and he told me they actually wanted to couch the details in the framing that each vendor used. Considering that Automic has a plug-in architecture that interfaces to many of these products, I suppose that makes sense. And making sense or not, it’s good for us, because we don’t have to pry apart two layers of vendor-speak to figure out how a product can help.

    If you’re trying to figure out the CD market, or a subset of that market, this is another good tool to have access to, so thought you all would be interested. The plan is to keep it up to date, so hopefully it is useful for a while moving forward.

    — Don Macvittie

  • DevOps Chat: Dead-End Computer Languages with Scott Wilson

    DevOps Chat: Dead-End Computer Languages with Scott Wilson

    Scott Wilson from Automic is always a great source of knowledge around DevOps. I have spoken with him several times and he never disappoints. In this DevOps Chat, Scott talks to us about dead-end computer languages. Scott, who is a developer himself, often marvels at the explosion of languages available today and wonders how many will survive beyond the useful life of the applications that they are written in.

    It is a great point. We did a survey a while back that showed the average organization is supporting upwards of 10 + languages concurrently. Talk about tower of Babel. Well, Scott gives us some great background on this.

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hi, everyone—Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode’s guest on DevOps Chat is Scott Wilson of Automic. Scott, welcome to DevOps Chat.

    Wilson: Thank you, Alan. I’m glad to be here.

    Shimel: Yep, and Scott, we’ve spoken before, we’ve done webinars and podcasts in the past, and are fairly familiar, but for our audience who may not know who Scott Wilson is, why don’t you give us a quick background?

    Wilson: Okay, great. Thank you, Alan. I am currently the product marketing director at Automic Software, and basically, I am specializing particularly in DevOps and application release automation.

    I come from a pretty technical background. I started basically in high school writing code. I was a software developer for a long time, and you know, in many evolutions, different vertical markets of writing code, and I’ve evolved ultimately now into marketing, so.

    Shimel: That’s not such a bad thing, Scott. But [Laughter]—there are fates worse than death.

    Wilson: [Laughter]

    Shimel: But anyway, Scott, we were gonna talk a little bit today about, you know, sort of, we can call them dead-end languages—and by that, I mean, you know, it’s a great time to be a developer today. You have so many choices in what you want to develop.

    But, like anything else, you know, there will be winners and losers among development languages that you can choose from. And I know this is a—

    Wilson: Absolutely.

    Shimel: – yeah, this is a topic you’ve spoken and written on. So I wanted to kind of, you know, with that premise, why don’t you explain to our audience a little bit about what you’re talking about?

    Wilson: Okay. Well, you know, as I mentioned in the intro, Alan, I am no stranger to code, and I will admit I still write code on the side for various things here and there. And one of the things that has struck me over my experience, especially with talking with customers and even working for a couple of vendors for application release automation products is that, in DevOps in general, there’s this great level of interest and experimentation going on with languages. A lot of the ARA tooling provides ways for you to build your own plug-ins, for example, so that you can extend these products and extend their reach into building a nice, cohesive tool chain—a DevOps pipeline, if you will.

    And the challenge is, as I started looking at a lot of these products and a lot of the momentum in DevOps is, I started realizing that people are choosing languages that are kind of dead on arrival already. What really sparked my interest in this was not only my observation here, Alan, but I spoke with an executive at a large company, and he was telling me that they were having to rewrite a lot of their DevOps code—their deployment code, if you will—because the folks that had written their pipeline five years ago used a language that they can no longer hire people to write it. And so they’re having to scratch it and rewrite it again, and I have actually heard this theme a few other times as I’ve met with executives across the U.S.

    So that had me really diving in and trying to figure out, well, how big of a problem is this? There is—and I won’t name the company, but there is one area vendor that does offer a PERL toolkit, just for example, to connect to their API and interact with it. The problem is, PERL is a dying language. So, if—now, this vendor also does not exclusively demand you use PERL, but I just found it an odd choice that they would even support that, given its decreasing popularity. Additionally, I was at a Chef conference this last summer, summer of 2016, and they announced their new Habitat write platform, and it was all written in Rust. Again, another odd, obscure language.

    And so, Alan, what I did is, I went around and started looking to find out, well, why are some of these companies choosing a language and then five years later, not able to support the language and the tool that they have built it in? And there are several, it turns out, popularity indexes, Alan, and you can look around for these. There’s one called the Popularity of Programming Language, PYPL, and it’s listed on GitHub, and it lists all the popularity—languages by popularity and share. There’s the TIOBE index as well, and there are several indexes. Some of them compile indexes, I think—what is it? There’s one that is garnered by what’s called Coding Dojo, and several others that go look at job listings to see what are the most popular language requirements in job listings.

    And if you wanna get a good sense of this, actually, you can actually go to ZDNet.com. They wrote a great article that basically took all the different indexes, aggregated them, and put them together. And what’s interesting in their findings is that you don’t see PERL, you don’t see Rust, you don’t see a lot of these, I call them doctorate languages, meaning people going to get their doctorates in computer science wind up creating these languages and they each kinda have their own cult following, Alan. Which is cool in one respect, but in the other respect, it means that if you’re not careful, you can latch on to some programming language for your DevOps practice and wind up choosing a language that is in fact not sustainable. That’s a trend, and you wind up—

    Shimel: Certainly—so Scott, in the case of Rust and maybe some of the other more obscure kinda languages we run into, I get what you’re saying and I don’t disagree, but you know, when you look at PERL, you know, you and I are not 20-somethings, Scott, right? I mean, PERL has been around a long time, and in its day, you know, back in the dot com bubble, you know, PERL was the equivalent of PHP, you know? And recently I saw, I think PHP is out—PHP 5 or whatever is out there now.

    But, you know, PERL—if you would have asked me a language to bet on in 1998, I probably would’ve bet on PERL. You know, I wouldn’t think it would become obscure or obsolete—though, look, ’98, you know, we’re talking 18, 19 years, and certainly nothing lives forever.

    But how are people out there—you know, it’s so hard. We don’t have a crystal ball, right? And we do have these indexes, but how do we know, like, what’s the next hot one and which is the next dud?

    Wilson: That’s an excellent question, and just to provide me the story, Alan, of your, what you’ve pointed out—because there is no crystal ball, and it is tough—I think the whole IT industry right now, including programming languages, it really reminds me a lot of the turn of the 20th century when there was really no clear definition of what an automobile should look like. And there were various versions—Edison had his battery operated vehicle, and there were several steamers, there several combustion engines and there were lots and lots of losers, lots of investments that went bust.

    And it took, you know, basically a couple of decades, but by the time we hit the 1920s, everyone understood and knew what an automobile looked like, and it looked like and operated like a Model T, right?

    And so it’s really kinda tough right now. So what I like to do, or what I recommend in the context of what we’re talking about here with languages is to really look at where it’s trending and what its longevity has been. If you look at that, you know, Java, C++ are popular. That might be, C have had, and even JavaScript have had a great deal of sustained momentum over a couple of decades.

    You were right—PERL, at the time, was great, but according to the popularity index, it is as its lowest popularity point since 2001 and is continually trending down. PHP has been holding its own, and in the composite index, it is still listed as one of the more popular languages.

    And so, you know, I would be—frankly, if I were practicing a language to help extend my DevOps practice, I would definitely look at what things have been sustainable over the last several years—decades, rather—and really look at the trending. And that’s why—and not to sound too critical, but when I look at Chef, placing Habitat on Rust, for example, was probably not a great idea for the future. If you look at what languages have sustained over the last 20 years, it would have been better for them to have chosen Java, because you have a huge base of Java developers and you could have then had a much larger contribution base to the project. So I think there’s just things you can do like that.

    And then, you know, the other thing, Alan, to your point—and it’s very unsexy to say this, but there has been one kind of, I’ll call it quasi-programming interface that has spanned the entire test of time and has remained consistent. And it also, what’s neat about this, is I have observed, it transcends every IT specialist, and then as a command line interface or a CLI. I’ve found, in looking at this, that it was very interesting that one of the challenges of, let’s say, extending some new fad DevOps tool using a programming language is that it requires a programmer, and you have to understand the grammar of the language. And that usually silos the expertise that is capable, or readily capable of picking this up. Where, versus a command line interface, they were designed, frankly, for the use case to be readily understood and easily picked up, and they transcend everybody, whether you’re a software developer, a DBA—everyone kind of gets to very quickly understand how command line interfaces work.

    So I’d be, if I were trying to build my DevOps practice today, I would actually be more keen on looking at using command line interfaces, published ones, to set up a lot of my extensions and automation mechanics, just because they have transcended time and have the longest life span of any language, though I wouldn’t say command line interface is a language, it is an interface, right? But the nice thing is, they are mostly self-documenting, where the programming languages, you have to know the language to understand what it’s doing, and they’re generally not self-documenting.

    Shimel: Got it. Scott, I don’t wanna put you on the spot, but give our listeners, if you can, what you think are your top three choices for the languages to use, let’s say, in the foreseeable future.

    Wilson: Alright. Excellent question. Well, as always, it depends on what you’re looking to do. That’s what’s very interesting when you look at the indexes and the aggregates and the composites of these indexes is, it really depends. I look at languages a lot like tools in a tool shed. They do a specific thing. You wouldn’t want to write a web server, for example, in C. I mean, you could, but you know, it has diminishing returns.

    I would say, in the modern cloud that we’re in, the more popular languages that would support this are certainly Java, you’ve got Python, PHP, JavaScript and C# are amongst the more popular ones. They’ve been around for a while. C#, as you know, is backed by Microsoft, a big company, and is recently going open source, the .net platform is. It works on every platform—Mac, Windows, Linux, what have you. So that could be interesting. JavaScript, I mean, for its ease of use? I mean, goodness, it’s been around for quite a while. You’ve got services like Node.js in which you can run very sophisticated apps on it.

    I’d probably be looking in that tier for the modern, cloud-based apps—Java, Python, PHP, C#, JavaScript would probably be the languages I would be more keen on looking at.

    Shimel: Got it. So, Scott, believe it or not, we’ve kinda used up our 15 minutes of fame, here. But you know, this is an interesting subject matter, Scott, that I think many developers sort of delve in. You know, there’s the, I call it the shiny trinket syndrome where everybody wants to use the latest and greatest cool tool, but sometimes, you know, these fads fade out quickly and you’re left, you know, with a fantastic product that was developed in a dead-end language, or a fantastic app developed in a dead-end language. So definitely something to be wary of.

    Wilson: [Cross talk] Yeah, like I said, the languages that are great for creating a project, if you’re trying to do a lot of those DevOps automation mechanics, I would really, highly recommend looking at command language interfaces to stitch a lot of that together.

    Shimel: Yep. So, Scott, we’re gonna call it a wrap on today’s podcast. Obviously there’s big news going on with Automic and acquisition news and stuff, and maybe once the dust settles on that, we could have you back on and talk about that a bit.

    Wilson: Absolutely. I’d love to.

    Shimel: Until then, though, Scott Wilson, Automic—continued success, keep doing what you’re doing, and thanks for being this episode’s guest on DevOps Chat.

    Wilson: Thank you, Alan. Have a great day.

    Shimel: Alright. This is Alan Shimel for devopsy.kinsta.cloud for DevOps Chat, and thanks for listening and we’ll see you on the next chat. Bye bye, everyone.

    — Alan Shimel

  • Automic Helps DevOps Transformation Sparkle

    Automic Helps DevOps Transformation Sparkle

    Working closely with Automic, an international wholesaler and retailer of jewelery transformed a department of project managers, developers and operations responsible for all of the customer-facing websites into a DevOps organization. As a result, project delivery was completed with 90 percent fewer delays, and first customer-facing releases of projects could be delivered in less than half the time. The usability of its websites increased significantly, resulting in more customer traffic, longer average time spent on the sites and increased revenue.

    Haphazard Development

    Prior to the DevOps implementation, new projects were delivered by “waterfall” project management means. The cyclical resource planning process was based on the project portfolio and business priorities. Project managers then planned project milestones working closely with business stakeholders, business analysts and application developers. Analysts created specifications and developers were assigned to work on packages and tasks to implement them.

    Different web technologies were used with varying levels of dev and ops expertise in each technology. The  Operations team members usually fulfilled requests made during the course of a project as part of their overall daily tasks—for example, to provision a new environment, deploy a package or change the environment configuration.

    This approach had a major disadvantage. Delays in one project impacted the overall resource planning and could have a cascading effect on other projects. Delays in projects could be for multiple reasons, such as waiting for business stakeholder impact, frequently changing requirements, unexpected sick leaves of developers or poor estimates. Other frequent causes included delays in operations tasks such as a deployment or provisioning of a new environment. These delays were caused by unaligned planning as well as a mismatch in priorities between projects and operations. Besides delays, some developers were underutilized, which also was exacerbated because they were specialized in a technology or component.

    DevOps Transformation Solution

    Working closely with the customer, Automic restructured dev and ops by:

    1. Switching the development from a project to a product mode (cross-project development teams based on capabilities rather than assignment of individual developers to projects).
    2. Moving project managers from development micromanagement to focus on major milestones and deliverables to the business.
    3. Enabling some project managers as product owners (project management remained necessary).
    4. Providing developers with agile methodologies through initial training plus ongoing coaching (six to 12 months).
    5. Providing ops with an agile methodology.
    6. Organizing both dev and ops into multiskilled teams focused on individual products rather than technologies.
    7. Aligning ops into delivery teams, initially part-time and later full-time.
    8. Giving delivery teams the end-to-end responsibility for their products, including their operations.
    9. Standardizing the technology stacks within teams (but not across them) over time.
    10. Delivering projects into production (or alpha, beta) in slices (releases) instead of just once to get early feedback and improve.

    Results: Fewer Delays, Better Usability

    By standardizing, this customer has transformed its dev and ops teams, creating an agile, scalable environment that can drive the business forward. The company achieved the following specific results:

    • Project delivery are now completed with 90 percent fewer delays. First customer-facing releases of projects now are usually delivered in less than half time.
    • The usability of websites has increased significantly, resulting in more customer traffic, customers remaining longer on the sites and increased revenue opportunities.

    About the Author/Michael Schmidt

    Courtney-Glymph_avatar_1435225162-96x96Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.

  • CA Technologies Announces Intent To Acquire Automic

    CA Technologies Announces Intent To Acquire Automic

    Acquisition to Provide Cloud-Enabled, End-to-End Automation and Orchestration Platform for Applications and Business Processes

     NEW YORK, December 1, 2016 – CA Technologies (NASDAQ:CA) today announced it has signed a definitive agreement to acquire Automic Holding GmbH, a leader in business automation software that drives competitive advantage by automating IT and business processes. The transaction, valued at approximately 600 million euros, net of cash and cash equivalents acquired, has been unanimously approved by both Boards of Directors, and is expected to close in the fourth quarter of CA’s fiscal 2017. Headquartered in Vienna, Austria, Automic has approximately 600 employees across Europe, North America and Asia.   

    With Automic, CA will add new cloud-enabled automation and orchestration capabilities across the portfolio and increase its reach into the European market. Automic’s European presence coupled with CA’s worldwide expertise and broad portfolio, offers customers a global solution that complements their existing technology investments to address the challenges of automation across the enterprise. 

    CA will add Automic’s automation and orchestration capabilities to its portfolio to give customers options that address their IT operations and DevOps needs on-premise, in the cloud and hybrid cloud environments. With real-time analytics incorporated into the end-to-end platform approach, customers will benefit from increased business agility with solutions that move from IT-centric task automation to business-centric intelligent automation and orchestration.

    “Global businesses need the flexibility and agility to move workloads to the most appropriate locations across heterogeneous hybrid cloud environments, with continuous availability, to stay ahead of their competition,” said Ayman Sayed, president and chief product officer, CA Technologies. “With the acquisition of Automic, we will deliver automation, scale work flows and business processes while reducing costs and greatly improving accuracy. This level of intelligent automation will give our customers the insights to achieve more agility and realize business value. We are pleased to welcome Automic, which is profitable and growing at a healthy clip, into CA.  Strategically, it accelerates our position with its cloud enabled platform.  Operationally, it expands our reach across Europe.  And, financially, it meets our rigorous hurdle rates while providing the highest likely return on offshore cash.”  

    Automic’s automation technology underpins digital transformation by helping enterprises move from siloed automation to intelligent and orchestrated automation with real-time analytics.

    “Enterprise customers are engaging with vendors to support their digital transformation initiatives to increase velocity, reliability and scalability among their businesses processes,” said Todd DeLaughter, Chief Executive Officer, Automic. “Together with CA Technologies, we will help organizations further propel their intelligent automation capabilities to the next level, driving the agility and speed demanded in this era of Digital Transformation.”  

    Founded in 1985, Automic has offices in Vienna, Paris, Asia Pacific Japan (APJ), and Bellevue, Washington and serves a wide range of customers in the energy, financial services, healthcare, manufacturing, retail and telecommunications sectors.  

    Foros acted as financial advisor to CA Technologies on this acquisition.

    Updated Guidance

    Assuming the transaction closes in early January, CA’s preliminary expectation compared with its previous fiscal year 2017 guidance, is that the acquisition will:

    • Add one-half percentage point of revenue, both as reported and in constant currency
    • Adversely affect GAAP and non-GAAP total company operating margin by 1 percentage point and will primarily impact the Enterprise Solutions segment
    • Be modestly dilutive to cash flow from operations and GAAP and non-GAAP diluted earnings per share, both as reported and in constant currency

    Please see below for information regarding non-GAAP financial measures, the cautionary statement regarding forward-looking statements, and the reconciliation of projected GAAP metrics to projected non-GAAP metrics. 

    About CA Technologies 

    CA Technologies (NASDAQ:CA) creates software that fuels transformation for companies and enables them to seize the opportunities of the application economy. Software is at the heart of every business in every industry. From planning, to development, to management and security, CA is working with companies worldwide to change the way we live, transact, and communicate – across mobile, private and public cloud, distributed and mainframe environments. Learn more at www.ca.com.

    — Alan Shimel

  • DevOps Chat: Lucas Carlson, VP Strategy, Automic, Can Ops Thrive In DevOps?

    DevOps Chat: Lucas Carlson, VP Strategy, Automic, Can Ops Thrive In DevOps?

    In this DevOps Chat our guest is Lucas Carlson, newly appointed VP of Strategy at Automic. Of course, Lucas has already had a distinguished career. Here is his bio from Linkedin:

    Lucas Carlson is an author, entrepreneur and executive. He also has a background of 20 years of programming to back it all up.

    He’s written scalable software that has been downloaded millions of times and used by millions of users. As a keynote speaker in the technology arena and innovation leader in the cloud space, Lucas helps companies discover opportunities for growth.

    Lucas wrote a bestselling book on Ruby for O’Reilly called The Ruby Cookbook and has created over a dozen open source libraries, some of which have been downloaded almost a million times.

    Lucas was formerly the CEO and founder of AppFog, a massively popular DevOps startup acquired by CenturyLink in 2013. AppFog signed up more than 100,000 developers, raised nearly $10M in venture funding and has become an industry leading Platform-as-a-Service.

    Before following his passion and writing books, Lucas served as the Chief Innovation Officer for CenturyLink, in charge of building next-generation Docker and Linux Container products for a $20B company.

    Lucas also writes for major tech and entrepreneur publications including Inc, Business Insider, InfoWorld and InformationWeek.

    I spoke with Lucas about why he joined Automic. Our discussion proved to be a provocative one, in which we explored Lucas’s view that DevOps is not a great thing for Ops. Ops needs its “own DevOps” that is more geared to its challenges and world view. Of course, many thought that DevOps is just that. Before you comment, have a listen to our conversation to see what Lucas said. I am interested in your thoughts and comments on this.

    Alan Shimel: Hi, everyone. Alan Shimel, editor of devopsy.kinsta.cloud here for another DevOps Chat. Very happy to be joined in this DevOps Chat by VP of Strategy at Automic Lucas Carlson. Lucas, welcome.

    Lucas Carlson: Thank you so much. Glad to be here.

    Shimel: Thank you. Lucas, I know you’ve been at Automic now, what, about two or three months?

    Carlson: Yep.

    Shimel: But I’ve known Lucas Carlson for years before Automic and I don’t know if our audience is familiar with you, but you’ve had quite a storied career already at a relatively young age.

    Carlson: Thank you. Yeah.

    Shimel: Why don’t you give our listeners a little bit of the Lucas Carlson story.

    Carlson: Sure. Well, I started out as a programmer: for 20 years I wrote code. I started code when I was in elementary school and ever since I’ve been writing code. And I wrote two programming books during my career. I’ve mainly focused on the open-source side of things so Ruby, PHP, Python worlds.

    And then I started a platform-as-a-service startup about seven years ago and I used Cloud Foundry as the foundation for my startup and it was called AppFog. We signed up 100,000 developers, it was a lot of fun. It was a great time.

    We were acquired by a telco and it was really interesting to spend a few years inside of a telco and watching them attempting a digital transformation—trying to move their applications into the cloud was a very interesting story.

    And after that I quit that job, I moved to Paris for a while—it was a life dream of ours—moved my family, and after Paris I looked around for what to do next and this opportunity came at Automic, and I thought it was a very interesting opportunity for reasons we might get into.

    Shimel: Great. Great. And of course, you know, interesting with your background and accomplishments Lucas that Atomic, which is an automation company, is where you wound up and as VP of Strategy there.

    So as someone who was a chief strategy officer at the last company I co-founded, Lucas, I can appreciate the title of VP of Strategy. But for our listeners who are saying, “Well, that sounds like just another corporate title,” give them a little insight. What’s your role as VP of Strategy at Atomic?

    Carlson: Yeah. Well, my role is to take a company that’s been around for almost 30 years that’s had a product that is battle tested, been around the block, really works, works at scale, has thousands upon thousands of enterprise scale customers, has a lot of pedigree and DNA, and yet is a company nobody’s heard of.

    That’s actually why I kind of joined. I thought it was a really interesting challenge to take a company that nobody’s heard of yet has had a product that is—has stood the test of time, is very, very robust, very strong, and see if there wasn’t a way to kind of help that company get recognized for the work that they do, which is actually really great work.

    And so I joined the company with that kind of concept in mind. And it’s been very interesting because fundamentally when I came into the company they called themselves a DevOps company and I come from a background—I’ve been doing DevOps for a long time. I grew up around Portland, I hung out with Luke Kaines who founded Puppet and he was one of my mentors when I was building AppFog and—so I knew DevOps inside and out. I used DevOps to build my own startup.

    And so I came in and I looked at what Automic had and Automic has a very interesting, strong product, but it’s not DevOps, because DevOps is predominantly—you know, having grown up around it I know you know DevOps is not some mystical union of developers and operations into this perfect combination that can do both and is just as adept at writing Ruby as they are debugging MySQL.

    You know, that’s kind of a story—a fairytale that people like to tell, but it’s not the truth. The truth is, DevOps was created by developers for developers to get around operations. They were sick and tired of waiting for operations to get around to provisioning their SQL server so they wrote some code that did it for them.

    They were tired of kind of the delays and lags so they wrote code that got around it. It wasn’t really meant to create this mystical union it was really meant to bypass operations.

    So, I guess, how does that apply to Automic? So, Automic came in saying they were DevOps—they weren’t a tool for developers and yet I thought they have this long track record. They’re doing something right, but what is it?

    And I spent a lot of time thinking about that before I joined and when I joined I became convinced that there is a huge part of the DevOps story that is getting left out: it’s getting forgotten, it is getting sidelined and ignored that doesn’t deserve to be ignored.

    I think that DevOps isn’t enough on its own. Having run a platforms and service company myself, having put platform as a service into major name-brand banks, having seen people trying to adopt these DevOps technologies—what I’m seeing over and over again is that one of the biggest struggles about DevOps is a myth that I’m trying to shatter. And the myth is that DevOps doesn’t need operations: that DevOps outsources operations, that operations isn’t necessary for DevOps.

    In fact, I think the absolute opposite is true and I don’t think ops is becoming part of dev. I think that ops deserves its own practices equivalent to what DevOps brought to developers. Equivalent and yet different, because I think that fundamentally operations was a different world of developers: always will, always has.

    To developers, failing fast is important and breaking stuff is totally acceptable. And going iteratively is great. So if you write some code, it doesn’t work you can fix it really quickly because you failed fast and it makes it better. And that kind of iterative approach is something that works really, really well for developers but it does not translate for operations. Operations cannot fail fast. If you fail in operations and your database goes down in production, that could be millions upon millions of dollars lost for the business.

    So it’s not that operations doesn’t want speed—of course they want speed, it’s just that speed is not the primary. For developers, speed is primary; for operations, reliability, robustness, scalability trumps speed. It’s not that they don’t want speed, it’s that they have a different core value set—a different world view—and instead of trying to mush these things together, instead of making them one idealized person that’s never going to exist, what I say is, let’s raise up the ops side of DevOps, bring it to the same level that developers have been raised. When developers adopted DevOps practices, it raised them up to a new level as a power-up—it was a mushroom in Mario. And what we need is to give the ops side a mushroom.

    We need ops to level up and be able to play at the same level as developers, but with tools built for operations, not built for developers.

    The tools out there for developers in DevOps are not the right tools for operations in DevOps and that’s what –

    Shimel: Hold on, I’m going to stop here because I’ve got to jump in—I’m sorry—I’ve been biting my tongue.

    So this is actually a pretty—I don’t want to say radical, but a very different kind of view of DevOps and what goes on between dev and ops than I think we hear from most people.

    And it actually reminds me I had a conversation—actually a DevOps Chat—with Dave West, who is the CEO of Scrum.org. And you know, obviously, Scrum and part of Agile is really aimed at developers. And though he saw sort of a potential bridge from dev to ops he had a similar view of yours that, you know, we have tools that are written for developers that developers are using that are letting them get more involved in ops but how much is ops really being involved in this DevOps, if you will.

    But yet, you know, let’s look—like configuration management tools.

    Carlson: Yep.

    Shimel: Do you think those are dev tools not ops tools?

    Carlson: Yep, I absolutely do.

    Shimel: Absolutely. And –

    Carlson: I could go into that more but I think it’s self-evident. I think that developers use those tools vastly more than operations. I think that the reasons are obvious. The tools were built for developers by developers.

    Operations looks at the world through a different lens; they use a different way of approaching the same problems and they kind of—the way that configuration management works embraces a development mindset.

    Shimel: Okay, fair enough. Let me ask—so how does this, Lucas, play into Automic and their future toolset? Will we –

    Carlson: Well, I joined Automic specifically because I saw this as the biggest problem in DevOps today and that Automic has solutions on the ops side of DevOps. Automic’s solutions are the level-up for ops teams. They don’t say—like one of my biggest pet peeves right now is this rip-and-replace mentality. You see it … with Mesosphere, with Docker containers, with Cloud Foundry, with OpenShift. All the big vendors out, there they all have the same promise: “Take everything you’ve done, throw it away, import all of your applications into our platform that will do it all for you and it will solve all your problems.”

    Well, I’m sorry, but that’s just not going to happen. Those platforms are generally underdeveloped, undertested at scale, they are a brand new way of managing applications that is untested. They don’t embrace the vast majority of enterprise scale applications architectures. They basically force you to rip and replace. And rip and replace is not just a thing for the code it’s a thing for all the IT processes that have been known to work for the last 10, 15, 20 years.

    So you’re trading a potential promise for a solution to all your problems, but the risks are exponential and vastly untested. So this whole concept of rip and replace I think is very, very dangerous in our industry today and very prevalent.

    And I joined Automic because their approach is to embrace what already exists and make it better. Instead of saying, “We’re going to have a new platform for you to import all your apps to,” they have a way to describe the topology of your existing infrastructure and built on top of that and automate that instead of throwing it out and replacing with something new.

    And so, I think to me, it really levels up the ops side of DevOps—it makes operations a hero, the co-hero of the DevOps story. It doesn’t deny operations their vital role.

    Shimel: Excellent. Excellent. You know what? Lucas, I’d love to see this at a Speak—you’ve got to submit to Speak about this somewhere.

    Carlson: Yeah, for sure.

    Shimel: Or, maybe we can do a webinar and get into it because honestly, our DevOps chat format being just 15 minutes doesn’t give us enough time to really delve in here and I’d love to get a counterview of these things too and let’s really have a discussion around it. I think I’m going to take that as my job. I’m going to go find someone and we’ll go back and forth on this.

    But unfortunately we are just about out of time—we’re at 15 minutes already. As I said, it goes quickly.

    Carlson: No problem.

    Shimel: This has been a very interesting discussion. I would call it truly an ignite or a fire starter in that you’ve opened the door here and we’re not finished with this one Lucas. We’re going to come back to it.

    Carlson: Sounds good.

    Shimel: But for now we’re going to call it a wrap. I hope if you’re listening to this you found the conversation interesting. Of course on devopsy.kinsta.cloud you’ll also see a written transcript of the conversation so you can hold Lucas to his words here and it’s going to be in writing.

    And if you have any questions, comments, feel free to also put them on devopsy.kinsta.cloud we’ll get them out to Lucas, and as I said we’re going to try to continue this discussion at a later date.

    But for now Lucas Carlson, VP of Strategy Automic. Thank you so much for really kind of blowing the doors up today on this and we look forward to seeing what the follow-up’s going to be. And success at the new position.

    Carlson: Thank you so much. I’m very happy to be here.

    Shimel: Thank you. Yeah, no, it’s a great company. We’ve worked with Automic for some time and I’ve met a lot of great people there.

    Anyway, that’s a wrap for this edition of DevOps Chat. Lucas Carlson from Automic was our guest and this is Alan Shimel for devopsy.kinsta.cloud. We’ll see you at the next DevOps Chat. Thanks everyone, have a great day.

    — Alan Shimel

  • Automic v12 Promises to Streamline Business Automation

    Automic v12 Promises to Streamline Business Automation

    Automic is in the business of automation. The company recently launched a unified suite of business automation tools called Automic v12 that promises to streamline operations even more.

    I wrote about Automic about a year ago. At the time, I noted how the name Automic is a sort of double entendre that has “auto” right in the name but sounds like “atomic,” which makes it sound very dynamic and powerful. I also wrote about being confused by what exactly Automic was offering. It was dubbed “continuous everything,” even though it seemed to focus on only three areas, and I wasn’t sure what the actual name of the product or platform was.

    That was then, this is now. Fast forward a year and it seems as though Automic—and its brand messaging—have both matured.

    According to its mission statement, Automic strives to drive powerful outcomes for customers in today’s global economy by automating their critical business processes. In the wake of five successful acquisitions, Automic reports double-digit growth and 2,700 enterprise customers representing a variety of key industry verticals. Apparently, the business of streamlining automation is booming right now.

    “Automic Release Automation (ARA) v12 is all about simplifying the steps necessary to utilize and maintain the solution to enhance the value proposition of the automation platform as a whole. The intelligent ‘Zero Downtime’ deployment and update capabilities are not simply about updating Automic agents with no downtime. They are also about removing infrastructure maintenance bottlenecks with intelligent software that can determine, for example, which agents are best updated at which time,” explains Julie Craig, research director at analyst firm Application Management Enterprise Management Associates in a press release statement. “With an enhanced REST API, customers can leverage ChatOps to use their favorite chat client to interact directly with the ARA platform while processes are in-flight, without going through a dashboard. Both of these new features are impressive differentiators which both current customers and prospects will likely appreciate.”

    In my opinion, one of the most valuable aspects of Automic v12 is that it is designed to leverage the infrastructure you already have. Automic can help you implement and manage a hybrid environment and embrace DevOps principles and practices without ripping out everything you’ve got and starting over.

    Beyond that, it is designed to facilitate automation, and automation is crucial for DevOps success. The new features in Automic v12 claim to remove maintenance windows, simplify management of core business apps and drive intelligent insights across your environment—connecting disparate islands of automation to enable more valuable business intelligence.

    If you are looking for ways to improve automation and embrace the continuous continuousness of DevOps, you should take a look at what Automic has to offer. Automic v12 might help you streamline and manage your DevOps environment more effectively.

    — Tony Bradley