Tag: cloud

  • Virtual Instruments Changes Name to Virtana to Drive AIOps

    Virtual Instruments Changes Name to Virtana to Drive AIOps

    With the formal launch of a software-as-a-service (SaaS) to monitor cloud platforms and optimize cloud, Virtual Instruments today renamed itself Virtana.

    The company’s CloudWisdom platform is based on technology Virtana gained via the acquisition of Metricly earlier this year. In addition to being integrated with existing on-premises offerings from Virtana, CloudWisdom has been expanded to include a self-service option. Downloadable trial versions are also available.

    Virtana CEO Philippe Vincent said the name change reflects a transformation from being simply a provider of storage I/O performance testing tools to becoming a provider of an IT operations management platform infused with artificial intelligence (AIOps). As part of that effort, the CloudWisdom offering represents the first time Virtana has extended the reach of its offerings beyond on-premises IT environments, he said.

    CloudWisdom will differentiate itself, Vincent said, because it combines cloud monitoring with built-in tools for optimizing cloud costs. Rival offerings require IT organizations to acquire two separate services, he noted. The CloudWisdom platform monitoring capabilities span databases, messaging platforms and containers, as well as cloud infrastructure services from Amazon Web Services (AWS) and Microsoft.

    In general, Vincent said IT organizations are moving away from a reactive approach to managing IT to a more proactive approach that will require increased reliance on automation. As IT environments become more complex, too many IT organizations are trying to compensate by overprovisioning IT infrastructure resources to make sure application performance doesn’t deteriorate or applications crash. That approach not only drives IT costs higher, he said, but it also makes those costs unpredictable.

    To address that issue, Virtana is combining CloudWisdom with an AIOps platform designed to be equally applicable in legacy IT service management (ITSM) and emerging DevOps environments. Organizations that have adopted DevOps will be at the forefront of the transition to AIOps because of the inherent fluidity and velocity of those environments, Vincent noted. Machine learning algorithms coupled with real-time monitoring, big data analytics, workflow engines and automation frameworks will enable IT teams to streamline ITSM and DevOps processes to become more efficient. The opportunity for Virtana is to disrupt a highly fractured monitoring category by leveraging AIOps to unify monitoring at an unprecedented level of scale and scope, he added.

    Virtana is not the only IT management platform provider that has identified the same opportunity; much larger incumbent providers of these platforms and a raft of startups are moving in the same AIOps direction. Vincent said Virtana will differentiate itself by pursuing a more application-centric approach to delivering on the promise of AIOps.

    It’s too early to say to what degree IT operations can be automated using AI. There’s general agreement that AI will play a significant role in automating IT, and the more standardized the IT environment is, the easier it is to accomplish. The challenge is, most IT environments today are still anything but standardized.

    — Mike Vizard

  • Before We Burn the Martech Silo

    Before We Burn the Martech Silo

    There’s an ongoing debate about where marketing technology (martech) should sit in an organization. Does it live with the CMO, the CIO, the CXO–a hybrid strategist with both IT and marketing background–or some collaboration? As technology use grows, it’s tempting to move martech under another role. Before we burn the martech silo, like how McDonald’s, Uber, Mastercard and others are doing, let’s look at the implications for DevOps teams.

    A recent article in PR Week cited a University of Texas study claiming “only 40% of a corporation’s marketing-related activities today report to the CMO.” Martech is being siphoned off into other areas–sometimes slowly, sometimes abruptly. It’s because the tech outweighs the marketing, at least in the eyes of the C-suite.

    In March 2019, McDonald’s announced they were acquiring Dynamic Yield for $300 million. Dynamic Yield rose to fame as one of the leaders in omnichannel personalization. Translation: they watch visitors searching, viewing and ordering. Then, they show those related results to other visitors. With the deal closed, McDonald’s announced they were eliminating their CMO position and creating an SVP of martech reporting to the CIO. Automating the customer experience with in-store kiosks and mobile app ordering is their top priority.

    Another case where mobile app ordering dominates, Uber clobbered both its CMO and COO in June 2019, right after going public. Their rockstar CEO said he wants to be more involved in day-to-day operations. Uber rolled non-martech functions into a VP of marketing communications. For Uber, martech is the product–an automated experience connecting riders and eaters with drivers. Everything else is branding and communications.

    There’s a third org chart option: the CXO, or chief experience officer. More digital customer interaction is forcing a partnership between technology and marketing insight. Mastercard hired its first CXO earlier this year, bringing in a veteran from the digital marketing industry.

    What do these three moves have in common, besides moving martech out of traditional marketing?

    • All have powerful, ubiquitous brands with huge recognition.
    • Their core product shouldn’t change much moving forward.
    • Personalization shapes their offers using global and local trends.

    Here’s the thing: Marketing automation automates what marketing knows. When the current and future requirements are clear, evaluating martech tools is easier. Moving martech out of branding, advertising and communication to IT sounds reasonable until you realize what you don’t know.

    The martech silo often houses hunters, not farmers. Marketers have different metrics. They discuss impressions, and click-thru, and time viewed, and calls-to-action, and conversions. Strategy and content often have more impact on results than the delivery technology. In a fast-moving environment with many product or service offerings, what works once may not work elsewhere. Creativity comes into play, with cycles of learning.

    In today’s SaaS model, marketing can pick a cloud-based tool and explore possibilities with minimal IT support. That’s good, until data and process accumulate, needing a bigger silo. Be careful. Burning the martech silo can be far worse for the organization than leaving it alone, even with all the shadow IT downside. No matter who does it, picking tools for a martech suite before understanding requirements is a formula for disaster. Without integrated marketing experience, IT is set up for failure. It can cascade into marketing failure and finger-pointing.

    For a fluid marketing environment, a CXO is best suited for the job. They speak the language of both sides, along with representing external customers and their experience. If your organization doesn’t have a CXO, modeling a DevOps team responsible for martech in that image is the next best option.

    DevOps solves the problem of speed marketing needs in making changes. Teams also have deep experience in maintaining applications and overseeing security IT wants. Many teams already have a product marketing person managing their software requirements. What a martech DevOps team needs is people with customer and digital marketing expertise. This include creative writers, graphics artists and advertising and social media specialists.

    If that sounds like a problem without a CXO running air cover, you’re right. Budget and headcount come from somewhere. Both the traditional marketing team and the IT team want input, perhaps even control. The key for a martech DevOps team is behaving as if the silo had disappeared, no matter what the org chart says. The DevOps leader should keep everyone informed, managing up and across. It usually means creating different presentation views, one for marketing, one for IT and maybe one for the CEO. Make sure everyone gets answers to their questions in their language.

    We’re going to have more martech moving forward. Creating effective martech DevOps teams is a priority, even without sweeping C-level reorganization. Don’t just burn the martech silo–reclaim the pieces that work for both marketing and IT and build the right team around the customer experience. If you need help getting started on a bigger martech mission, let’s talk marketing strategy.

    — Don Dingee

  • IBM Extends z/OS Toward DevOps Again

    IBM Extends z/OS Toward DevOps Again

    A few months ago, I wrote about the release of Zowe, the first Open Source project based on z/OS. Zowe is a framework for including z/OS in your applications with less pain than we have traditionally suffered. IBM supported this project as part of its view that enterprises need to have interoperability between platforms.

    This belief also drove IBM’s recent announcement of new pricing models, along with enhanced cloud and container support that will help users tie mainframe access directly into the DevOps toolchain.

    First, let’s cover the pricing. IBM has brought “Pay as you grow” type pricing to the mainframe. While owning a mainframe means you are already expending funds, the new model is designed to simplify licensing and adjust what you are paying based upon actual consumption. It’s not a revolutionary idea, but it is wholly new to the mainframe scene and places mainframe pricing in the same pre-determinable model as cloud. IBM signed on some of z/OS’s biggest developers to offer similar pricing with Broadcom, BMC and Compuware either joining with IBM or offering similar programs.

    And Containers!

    But that’s not the exciting part for those of us in DevOps. The exciting part is the announcement of IBM z/OS Container Extensions. The ability to drop standard containers onto a z/OS partition and use them as an interface to traditional mainframe data/subsystems is huge from a DevOps perspective. This puts both the processing power of the mainframe and the stable data/subsystems into the DevOps cycle by allowing containers to be treated like any other container. Of course, I haven’t (and due to current work requirements probably won’t) played with it, so I’m likely glossing over some issues that users will run into, the potential is staggering. To finally have mainframe access that fits into the DevOps toolchain like any other system would is huge, and shows that IBM is listening to the market. I’ll be following along to see how it rolls out; I’ve got a fair number of associates working in mainframe shops who will keep me posted, but if you roll out Container Extensions, please let me know how it went.

    Cloud Interop?

    I’m less excited about IBM z/OS Cloud Broker. This announcement talks about the ability to spin up z/OS environments in IBM Cloud Private. It seems to me that this is counter to most users’ needs, but I can see that some larger z/OS environments might well have asked for it—rather than pull in another mainframe just for seasonal bumps, the ability to provision in the cloud is appealing. However, the number of organizations that fall into this category is small, though important from an “IBM customer” perspective, so it makes sense that the company went this route, but it’s less about new technology and more about giving important customers a tool to avoid large “forklift” upgrades, IMO.

    And Containers!

    I’m still thrilled to see Container Extensions. I’m looking forward to following where that goes. IBM has been pretty open about the fact that this is a road it is on, not a destination, so no doubt Container Extensions is just a stop along the way. But if it makes it easier for today’s crop of developers and DevOps engineers to access the mainframe sitting in their DC, I’m all for it, and can’t wait for the next stop on this road.

    — Don Macvittie

  • Insight IGNITE: DevOps, Cloud and Cyber From Iceland With Love

    Insight IGNITE: DevOps, Cloud and Cyber From Iceland With Love

    I had the pleasure recently of attending my first Insight IGNITE event, which was held at the ION Adventure Hotel in enchanting Iceland. It was also my first trip to Iceland. These two new experiences combined to deliver an excellent learning and networking experience, resulting in me realizing more than several new insights (pun intended) around DevOps, cloud and cybersecurity, as well as mindfulness and contentment.

    The agenda for this particular IGNITE event featured some great examples and discussion around DevOps, cloud migration and infrastructure and cybersecurity, among several others. All three of these were right in my wheelhouse, so I really enjoyed the presentations and discussions. I couldn’t type fast enough to keep up with all of the insights I was soaking in. Of course, I was also trying to contribute to the conversations, which are held in a very open, communal manner under Chatham House Rules.

    You may not be familiar with the Insight IGNITE Innovation Roundtable Series. They are the brainchild of Insight Partners’ Emmet B. Keeffe III. Emmet is beyond passionate about digital transformation (among several other passions including Formula One racing, world peace and now mindfulness/contentment). Utilizing his vast network (and it is vast), Emmet founded Insight IGNITE, an innovation program that delivers Innovation Briefings, the Innovation Roundtable Series and Growth Advisory Board opportunities to global IT leaders. I know that sounds like marketing speak, but let me explain.

    Basically, Emmet holds about one of these events a month at some of the most fascinating venues on earth. Each one has ~50 people. There is a mix of C-level executives from some of the 200+ Insight Partners portfolio companies, along with executives past and present from large global enterprises, sprinkled in with a mixture of technology experts and subject matter experts (I guess that is what got my ticket punched). The agenda is an exhilarating mixture of roundtable discussions and presentations on subjects touching on Digital Transformation, along with exciting activities that allow attendees to experience the local venue.

    The events are open to Global 2000 executives and other business and technology experts who think they could both benefit from this type of experience as well as have something to offer.  You can reach out to Emmet’s team if you are interested in attending one of these events.  Most attendees have to cover their own airfare/hotel. While not cheap, it is well worth the money, and the IGNITE team, who are extraordinary, do an amazing job of keeping it fresh, fun and challenging.

    The real special sauce of the IGNITE Roundtable Series, though, is the passion, caring and love that they receive from Emmet’s team. It is infectious and spreads to the attendees as well. I have attended hundreds of conferences over the years and don’t remember one where I made as many connections, had as many great side conversations and really felt part of a group. I am sure many of the people I met at this event I will be in touch with and doing business with in the months and years ahead.

    I met Emmet about three or four years ago in London (where he lives with his family now) and was invited to a previous event or two but was unable to make it. Since then, it seems Insight Partners is investing in so many of the companies that we work with here at MediaOps in DevOps, containers and cybersecurity—including Tricentis, JFrog, Aqua Security, Firemon and others. If you can’t beat ’em join ’em, as they say, so I decided to take Emmet up on his kind invite and check it out.

    The IGNITE event in Iceland had several great presentations about disrupting your own company product by spinning up the disruptor internally. We heard from “a queen of transformation” who has led transformations at several large multinational and government agencies. Another presentation focused on how an energy company keeps transforming as it stays ahead in today’s ever-shifting market and sets the bar for what the energy company of tomorrow looks like. In addition, there were some great panel discussions on the current state of DevOps and Agile, another on the state of cloud migrations, hybrid cloud and next-generation infrastructure. Also on the agenda was a great discussion regarding what is happening in cybersecurity and how critical it has become as part of any transformation. All of these were great, but what made them better was the great discussions they sparked among the attendees.

    That was not the full roundtable agenda, though. We also had a private briefing with the first lady of Iceland, discussions on some new fintech companies and technologies, AI/ML and more.

    But perhaps some of my favorite presentation and discussions were on a new passion of Emmet’s called the Contentment Foundation. This is a breakthrough effort to bring a new take on making education better for the world of today and tomorrow. Led by Dr. Daniel Cordaro, it recognizes that children are truly our future. How can we make them more content and mindful, better equipped to handle the world of tomorrow and the challenges they will face? The Contentment Foundation has developed a curriculum that is available to just about any school in the world. If you know a school that you think could benefit from this, I encourage you to reach out to them.

    All work and no play would make for a boring event, though. My trip to Iceland at the Insight IGNITE Roundtable was far from boring. We visited the famous Perlan Planetarium (which, unfortunately, was as close as I got to seeing the Northern Lights on this trip); ate in a Viking-themed restaurant; and rode ATF vehicles through the rugged, lava rock-strewn, stream-filled Icelandic countryside. We explored a lava tube cave and more. Unfortunately, the weather didn’t cooperate, so we had to cancel snowmobiling, whale watching and dinner on an island off the Iceland coast. I stopped off before heading to the airport to explore a bit in the capital of Reykjavík, which is a great little city with great cafés, shopping and sights.

    Even the social activities provided some great bonding and networking opportunities. It is rare for me that I not only make business acquaintances, but also form friendships at events like this. To me, this was yet another unique feature of the IGNITE Roundtable: People were there genuinely to share their experiences and discuss the burning topics at hand.

    All in all, one of the best events I have attended in a long time. I highly recommend attending at least one of these IGNITE Roundtables, if this sounds like something you may be interested in. As for me, I am already looking at what is the next one I will be able to attend. Once I have had a chance to digest and percolate on some of the insights I experienced, I will share a follow-up article to share them with you.

    Thanks, Emmet and IGNITE team, for a great experience.

    — Alan Shimel

  • DevOps Chat: Serverless and Abstraction with Nimbella’s Anshu Agarwal

    DevOps Chat: Serverless and Abstraction with Nimbella’s Anshu Agarwal

    Anshu Agarwal has a tremendous record of working in startups that had successful exits. Now for the first time, along with her co-founders, she is actually founding the startup herself. Nimbella is a serverless platform that is cloud-agnostic and makes developing and deploying applications easy. Whether in a public cloud, private data center or both, Nimbella can help.

    In this DevOps Chat, we speak with Anshu about her own personal journey and where Nimbella is and what the plans are for going forward.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hello, everyone, it’s Alan Shimel of devopsy.kinsta.cloud and you’re listening to another DevOps Chat. Today’s chat actually features a company that’s just starting out here, but it’s a guest who’s had a rather long career in the tech space. As long as mine, even, at some point, but I’m sure I’m much older. Anyway, I’d like to introduce you to Anshu Agarwal. And, Anshu, if I messed up your last name, I apologize. Was that good?

    Anshu Agarwal: Thank you, Alan. You said it perfectly right. Thank you for having me today.

    Shimel: Thank you. So, Anshu, let’s start off – I referenced that you’d been in tech a while. Let’s give people an idea of your personal journey that brings you here today, even going back to Speedera and beyond, if you’d like, but if you wanna start with Speedera, that’s fine. But let’s give folks an idea of who you are, what your background is.

    Agarwal: Sure. Thank you. So I am an engineer by background and I moved into product management and marketing after I finished my MBA. And, after that, I joined a startup and then the startup bug never left me. So I joined Speedera, which got acquired by Akamai. Then I joined another startup, Ankeena, which got acquired by Juniper. Another startup, ConteXtream, got acquired by HP. And my most recent startup, Cedexis got acquired by Citrix, so I have been acquired four times. And, in all of those companies, I kind of delivered the success for other people’s ideas because they were all successful startups, got acquired by very, very large companies, so they were indeed – from value standards, they’re considered successful, but, for myself, I had never really done a company of my own.

    So, when I got the opportunity of just starting and being a founder of a cloud infrastructure, because that’s my background – I’ve been doing cloud infrastructure for last 15 to 20 years – there was no question that I wouldn’t do it. And we got started on this company – the company name is “Nimbella.” And it is in the serverless framework or serverless platform space. And we are kind of disrupting what serverless is, so – or we are providing what serverless promises to the developers. So that’s what we are working on now.

    Shimel: Excellent. You know, you’re way too modest and humble because, for many people listening, whether they’re in the valley or Boulder or Austin or New York or Boston or London or Bangalore or anywhere else in this world, having four startups that were acquired by companies like Akamai, HP, Citrix, and I forgot the fourth one – I apologize – a lot of people would call that a career. Right? I mean, whether they founded the companies or not, just being associated with four companies that had successful exits to large companies like that is something to be proud of and it speaks volumes as to either you’re really, really lucky or you’re doing something right. Right? So congratulations to you for that.

    So you’ve mentioned Nimbella and I wanna kind of share with our audience up front that Nimbella is – you have raised some funds for the company and there’s a great startup – there’s a great founders group involved. You mentioned, I think, one of your cohorts from Speedera; I think there’s two other founders in the group. But the company’s sorta still – I don’t wanna say stealth, but pre-product, let’s call it. Pre-public-product. So I don’t wanna put you on the spot. I’d rather talk, I think, if it’s okay, Anshu, about some of the problems you see and potential solutions that we see.

    You know, we live in a great time for developers and engineers. Internet time, right? We’ve gone from servers to hypervisors to containers. Now serverless. And serverless seems to be all the rage, but, like any new technology, it’s not birthed mature, right? It doesn’t come out mature; it doesn’t start mature. And so there’s gonna be growing pains. Can you share with our audience a little bit about what you see as some of the growing pains around serverless or what you’re hearing from people around that?

    Agarwal: Absolutely. Well, thank you for – this is a great question because it is definitely the best thing that’s happening for developers. The reason I say that is because what developers really want is to develop their business logic or develop the code and not worry about the infrastructure. And serverless promise is all about that, that you don’t have to worry about the infrastructure. You don’t ever have to worry about how it scales, how it is secured. Anything that requires the knowledge of infrastructure should not be a developer’s worry.

    But, in today’s serverless frameworks – and there are a few serverless frameworks and some are very popular ones – there is so much complexity still for the developers because they have to combine many services. And, for instance, they have to think about storage, they have to think about identity management, and they have to learn all these services and integrate. Not only that, the management and debugging is still an issue. And these are growing pains, as you mentioned. The serverless computing is still in a nascent stage and, therefore, it’s lacking all the abstractions that are needed for the adoption to accelerate into new markets and application domains.

    Not only that, serverless today, if you look at it, is used only for stateless applications, so you’ll see it in IoT applications, you’ll see it in reactive kind of applications only. It is not suited for long-running or stateful workloads. The reason being is because serverless today is serverless compute; it is not serverless storage. So that’s another problem. We may consider it as a problem or we may consider it as the limited adoption of the technology, but that’s something we have to address if we want this to be adopted in general, across all workloads. Then the –

    Shimel: I’m sorry. We may also consider it as an opportunity, right? I mean –

    Agarwal: Oh, absolutely.

    Shimel: Yeah.

    Agarwal: Absolutely. And that’s what we’re doing. And I’m gonna talk about Nimbella and how Nimbella is addressing it.

    Shimel: Mm-hmm.

    Agarwal: Another important aspect of serverless today is, like any new technology environment, there is serious vendor lock-in because, if you are using AWS’s Lambda serverless framework, you are programming to the nuts and bolts of Lambda. If you are using Google, you are programming to GCP, and so it is with Microsoft Azure. So, in a sense, you are programming to proprietary frameworks and, therefore, your code is not cloud-portable.

    So, tomorrow, if your company decides that, “Now we are going to move from AWS to Google,” you gotta rewrite the whole thing again. So that is actually, again, the serverless promise, and, therefore, vendor lock-in is very real, especially for the companies, actually, that choose not to go to public cloud because they’re part of regulated industry or whatever _____. They want something to be running in their own private cloud; these serverless frameworks are not an option for them. And then, say, you were able to write code for all different frameworks, but then the complexity of operations is there because you can’t monitor and observe at each level since these are proprietary frameworks across these clouds.

    So there are serious issues for widespread adoption and that’s where we come in. That’s the opportunity we looked at when we decided to create this company, is we want to create a platform, a framework, that is providing all the necessary abstractions so the developer is not to worry about how the infrastructure works, how to scale the code, how to secure the code. The code is just nebulous logic that they write. Then it is also suited for long-running, stateful, streaming workloads, such as AI/ML workloads. I mean, we have a greater adoption of AI happening in every industry. If we are not going to be able to handle AI workloads, we are missing a big market.

    And those are real, real problems and we are addressing it with Nimbella, you know, the technical problems. Then there are operational issues where you want cloud portability, so we are also addressing that part because we are providing a layer of abstraction and it’s open-core-based, so a developer can program the way they program the business logic and not worry about which cloud they’re writing.

    Shimel: Got it. Got it, got it, got it. So, again, I don’t wanna be uncomfortable or make you uncomfortable with what we’re gonna talk about, but, you know, I was at KubeCon out in Seattle last month – seems like a year ago, but it was only last month – and, surprisingly or not surprisingly, “serverless” seemed to be on everyone’s lips. Right? And maybe some people listening to this are saying, “Wait a second, Kubernetes is for containers and containers can run on bare metal, yeah, but they run on VMware or hypervisor as well.” What do you think the role of Kubernetes is in the serverless future? Fair?

    Agarwal: Kubernetes is a great technology. I really think it has great future. And serverless frameworks use Kubernetes or something else like that. And we were also at KubeCon. It was actually our first conference as an Nimbella person attending – one of my cofounders, who actually is the creator of OpenWhisk Apache, a serverless framework, he attended it. And he mentioned the same thing that you mentioned, that serverless was on everybody’s slide deck. Okay? It is something everybody is looking at; it is something everybody is kind of they have it on their roadmap, that they wanna work on it. They wanna look at it and see if it works for their environment.

    And Kubernetes is perfect, actually. It provides the platform needed because it is widely accepted these days and it provides the necessary environment, but, again, it should not be the burden of a developer to know how to run, work with Kubernetes. It should be the infrastructure serverless framework that provides that to the developer and the developer’s still only programming the logic. It’s not for the developer to worry on what environment, what container environment they are working on and what VMs are being used and what bare metal is being used. That’s all abstracted away for the developer.

    Shimel: Got it. Got it, got it, got it. So, you know, I’m sure there are people listening to us today who are thinking to themselves, “This woman has been in four startups and has had tremendous success.” And now I’m sure you’re a CEO, right, of Nimbella and you’re cofounder –

    Agarwal: That is correct.

    Shimel: Right? And I’m hoping there’s a whole bunch of women engineers out here or women entrepreneurs who are listening to you, saying, “Hey, if she can do it, I can do it.” And we don’t have a lot of time left, but I wanna address those folks there, that are near and dear to me for a lot of reasons. What’s your advice to them?

    Agarwal: Absolutely. If I can do it, they can do it. That is a very true statement. And, I mean, you said some great words about me, but I consider myself average successful person and, yes, I have been lucky that the four companies I’ve worked for had great exits. But being a founder and CEO is still very different from what I did for the other companies before. So, basically, when you are part of the company, other companies, you’re not bothered by operational aspects of the company. You’re not bothered by hiring for every possible function in the company. So the skill sets that I’m developing now, there is no other experience that could have taught me that, so, even though – I say, “Everybody can do it and anybody can do it,” but they still have to learn the art of running a company on the job. It just – there is no course. There is no education that can be given because you have to experience it.

    So, to all the women engineers that are listening, I would say, “If I can do it, you can do it. You just have to just get into it. You just have to dive into it and it will come to you. You will develop your advisors. You will develop the people who help you on the way because you won’t have all the skill sets, but you will know who to go to for what skill set, as you take that role.”

    Shimel: Absolutely. Absolutely. And, you know, women or not women, entrepreneurs – I’ve also founded and helped start my fair share of companies – I don’t know if it’s courage or just pure moxie, if you will, right? You just put one foot in front of the other, right, and you just keep moving forward. And you can’t boil the ocean, right, but you can – these things are incremental, right, and they’re evolutionary. They’re not _____ –

    Agarwal: Absolutely. You’re absolutely right. These are such an incremental thing and you may be not finding the best solution, but you are optimizing your solution, at every step, because you’re trying to handle so many things and, if you wait for the best solution to arrive, it may be too late. So you’re kind of optimizing the solution for whatever issue or whatever problem you’re handling, and you move on with that. And it’s just only time will tell how successful I am in the role, but this is my experience six months into this company, six or seven months into this company, and I’m still learning the art.

    Shimel: Absolutely, it is. So what do you – short-term future, where can we find out more on Nimbella or when will we find out more, do you think?

    Agarwal: Oh, absolutely. So there is some information on the website – very little information, I would say – but it gives you a flavor of what we are doing. Then, in Q1, this quarter, we are going to be releasing our developer playground, which is actually – because the buyer of serverless technology is the developer and developer experience is the most important thing, a developer has to feel one with the programming experience. And that’s the true serverless promise and we wanna deliver on that promise, so, in Q1, we are going to release that.

    And, in later quarter, in Q2, since I have mentioned private cloud and hybrid cloud, there will be offering for private cloud in Q2. So, as this quarter progresses, we are going to populate the website more with the content and we’re going to host more meetings like this and make it available to the developer community in general, our solution, and then, later on, for enterprise sites.

    Shimel: Great. Great, great, great. Anshu, when I started, I said, “These are only about 15 minutes. It’s gonna go so quick, you won’t believe it.” If I told you we’re closer to 20 minutes already, you’d probably say, “Oh, my,” but we are and we’re gonna need to call an end to this DevOps Chat. You know what? It sounds like there’s a lot going on here and, if we can have you back on, you know –

    Agarwal: Oh, that would be great, Alan. I really hope we can –

    Shimel: Yeah?

    Agarwal: I really hope we can get back when we have our developer playground because I’d love to talk more about it.

    Shimel: I promise you we will.

    Agarwal: Thank you.

    Shimel: Promise you we will. Thank you. Anshu Agarwal, founder/CEO of Nimbella, our guest here on this DevOps Chat. This is Alan Shimel and you’ve just listened to another chat.

    — Alan Shimel

  • Red Hat Tightens CloudForms Integration with Ansible

    Red Hat Tightens CloudForms Integration with Ansible

    Red Hat has tightened integration between CloudForms, its tool for managing IT infrastructure on-premises and in the cloud, and the its Ansible framework for automating IT operations.

    Pete Cruz, product marketing manager for management for Red Hat, said version 4.7 of Red Hat CloudForms and Ansible together promise to make it easier to manage multiple IT environments running on-premises and in the cloud using a common set of tools. Most IT organizations today are trying to manage at least one public cloud alongside their existing IT environment. Rather than having to master a separate framework for each IT platform, IT organizations can employ multiple Red Hat tools and frameworks to unify the management of multiple clouds and their internal IT operations, said Cruz.

    Version 4.7 of Red Hat CloudForms now makes it possible to execute Red Hat Ansible Tower workflows directly from CloudForms deployed on-premises. Those workflows can already be extended to include multiple clouds.

    With this release of Red Hat CloudForms, Red Hat is continuing its effort to extend its reach into the management of networks and servers. CloudForms is now integrated with Lenovo Clarity, a set of systems management tools, and Nuage Networks’ Virtualized Services Platform (VSP). Integration with networking platforms is becoming increasingly pivotal because internal IT organizations are now being asked to be as agile as a cloud service provider, said Cruz, noting it’s not especially useful if an IT organization can spin up a virtual machine in a matter of minutes but must wait weeks as network services are provisioned manually.

    Red Hat is trying to lay a foundation on top of which best DevOps practices can be extended across multiple IT environments. With each additional cloud service an organization adds, the less agile the internal IT organization becomes, unless it finds a way to centrally manage all the platforms being employed using a common set of tools, noted Cruz, and the only way to effectively manage IT at that level is to rely on automation frameworks.

    Unfortunately, the number of organizations that are haphazardly embracing multiple clouds seems to outnumber greatly the number of organizations defining a strategy for unifying the management of hybrid clouds. But as the operational costs of managing multiple clouds becomes more apparent, the pressure to unify the management of multiple public clouds and on-premises IT environments inevitably will rise.

    In the meantime, savvy IT leaders are trying to ensure their organizations don’t become overly dependent on any one cloud service provider. The deeper an IT organization dives into the management frameworks provided by cloud service providers, the more difficult it potentially becomes to move an application workload, should the need arise. It does not follow that because a workload was built on one platform it never will move off that platform.

    Naturally, Red Hat, which is scheduled to be acquired by IBM, is not the only vendor with an eye on the rising need to unify the management of hybrid clouds. But the one thing that is certain is that even before the deal closes, Red Hat is aligning its portfolio to specifically address that opportunity.

    — Mike Vizard

  • ‘DevOps Engineer’ Title Lands in Top 5 of Dice Salary Survey

    ‘DevOps Engineer’ Title Lands in Top 5 of Dice Salary Survey

    The position of DevOps Engineer is gaining some serious respect, and with that comes cash.

    In Dice’s recently released “2019 Tech Salary Report,” DevOps Engineer now ranks in the Top 5 of all tech salaries, with an average of $111,683. The survey is based on the responses of 10,780 technology professionals conducted between Oct. 22 and Dec. 13, 2018.

    It’s the first time that the title of DevOps Engineer has appeared in the Top 5, according to Dice. The one caveat is that the position might not be as popular as the annual salary suggests; rather, more professionals now identify with this position.

    What it does mean is that the DevOps Engineer title is now ranked with more established tech titles, including senior leadership positions CEO, CIO, Vice President and Director, with an average salary of $142,063; System Architect, at $129,952; Tech Management, including Strategist and Architect, at $127,121; and Product Manager, at $114,174.

    Overall, the average salary for tech workers remained relatively flat year over year. In 2018, the average salary totaled $93,244, a less than 1 percent increase from 2017, when the average salary stood at $92,712, according to Dice.

    In an email, Dice CTO Klavs Miller noted that the increasing use and adoption of various cloud-based technologies is pushing enterprises to invest more in DevOps engineers to take advantage of that compute power to develop new apps.

    “Many DevOps Engineer job requirements include a heavy focus on the creation of infrastructure as code, essentially transforming operations into the management of codebases that create infrastructure (in cloud services or native cloud infrastructure rather than servers and hardware),” Miller wrote. “We are also seeing and experiencing first-hand that more and more organizations are moving toward having combined development and operations teams around a domain, rather than splitting along traditional functional lines.”

    In his email, Miller noted that while there might be few tech pros that use the “DevOps Engineer” title, it doesn’t mean that there’s an actual lack of engineers with the skills to help enterprises with their DevOps projects.

    Instead, it’s a matter of looking for talent that might already be there.

    “There is probably a shortage of talent that label themselves as ‘DevOps Engineers,’ but employers should look at the skills required by those roles instead,” Miller noted.

    “There’s a growing demand for a skill that is still evolving with market trends,” he added. “As an example, DevOps is not nearly as common as its more common sibling, software engineers, but it has become more popular each year according to our salary survey and among employers who are sourcing Dice for these positions.”

    The types of enterprises looking for DevOps talent are varied. Right now, insurance company Geico and hardware store giant Lowe’s are each looking for specific DevOps titles, according to Dice.

    If private business isn’t your area, the Louisiana Economic Development agency is currently advertising for an entry-level DevOps position.

    In addition to specific tech titles, the Dice report shows that several types of programming languages that are now associated with the DevOps discipline are commanding significant salaries in the market.

    For instance, those with expertise in Google’s Golang programming language can command salaries of up to $132,827, according to the Dice survey.

    A little further down the line, and keeping with Miller’s emphasis on cloud-based technologies driving much of the DevOps conversation, those with knowledge of Amazon’s DynamoDB and Redshift can command salaries of more than $125,000 on average, the study found.

    Additionally, platform-as-a-service (PaaS) skills can net a developer an annual salary of more than $122,000.

    In his email, Miller noted that it’s difficult to draw a direct line between needs for certain programming languages and the growing popularity of DevOps. The growing reliance on cloud and the types of digital transformation projects enterprises are engaged with now show how the market has shifted.

    “There are some assumptions that we can’t confirm, but DevOps shares programming languages with other roles that are also in demand, as employers adopt cloud-based technology and open source becomes more pervasive in companies’ tech stacks,” Miller added.

    — Scott Ferguson

  • Cloud Waste To Hit Over $14 Billion in 2019

    Cloud Waste To Hit Over $14 Billion in 2019

     The good news to start 2019 is that cloud adoption is growing rapidly. Most people realize this, but along with major growth comes some less welcome news. Wasted cloud spend is also up—often dramatically. Chances are, if you’re spending money on cloud, some of that money is being wasted. For some, a lot of that money is being wasted. Here are the numbers.

    Predicted Cloud Spending 2019

    The latest predictions from Gartner estimate that overall IT spending will reach $3.8 trillion this year, a growth of 3.2 percent over IT spending in 2018. Of this spend, public cloud spending is expected to reach $206.2 billion—of which, the fastest growing segment is infrastructure as a service (IaaS), which Gartner says will grow 27.6 percent in 2019 to reach $39.5 billion, up from $31 billion in 2018.

    Now we can subdivide the public cloud spend number further to look just at compute resources—typically two-thirds of cloud spend is on compute, or about $26.3 billion. This segment of spend is especially vulnerable to waste, particularly from idle resources and oversized resources.

    Wasted Cloud Spending from Idle Resources

    Let’s first look at idle resources. This includes resources that are being paid for by the hour or minute, but that are not actually being used. Typically, this kind of waste occurs in non-production environments; that is, those used for development, testing, staging and QA. According to internal data available to my company, ParkMyCloud, about 44 percent of compute spend is on non-production resources.

    Most non-production resources are only used during a 40-hour work week, and do not need to run 24/7. That means that for the other 128 hours of the week (76 percent), the resources sit idle, but are still paid for.

    What does all this add up to?

    $26.3 billion in compute spend x 0.44 non-production x 0.76 of week idle = $8.8 billion wasted on idle cloud resources.

    Wasted Cloud Spending from Oversized Resources

    The other source of wasted cloud spend is oversized infrastructure; that is, paying for resources at a larger capacity than needed.

    RightScale found that 40 percent of instances were sized at least one size larger than needed for their workloads. Just by reducing an instance by one size, the cost is reduced by 50 percent. Downsizing by two sizes saves 75 percent.

    The data we see in our users’ infrastructure confirms this, and in fact we find that it may even be a conservative estimate. Infrastructure managed in our platform has an average CPU utilization of 4.9 percent. Of course, this doesn’t take memory into account, and could be skewed by the fact that resources managed are more commonly used for non-production resources. However, it still paints a picture of gross underutilization, ripe for rightsizing and optimization.

    If we take a conservative estimate of 40 percent of resources oversized by just one size, we find the following:

    $26.3 billion in compute spend x 0.4 oversized x 0.5 overspend per oversized resource = $5.3 billion wasted on oversized resources.

    Total Cloud Spending to be Wasted in 2019

    So, between idle resources and overprovisioning, wasted cloud spend will exceed $14.1 billion in 2019. In fact, this estimation of wasted cloud spend is probably low. This calculation doesn’t even account for waste accumulated through orphaned resources, suboptimal pricing options, misuse of reserved instances and more.

    Fortunately, cloud cost control is becoming top-of-mind as the industry is able to leverage cloud computing growth statistics to calculate the massive scale of this problem. If you are involved in your organization’s cloud  infrastructure, why not make reducing cloud waste one of your 2019 objectives?

    — Jay Chapel

  • DevTest Scales Out in the Cloud for 2019

    DevTest Scales Out in the Cloud for 2019

    It’s 2019, which means a whole new year of advancements in all areas of technology. One topic that is near and dear to my “cloud” heart is the acceleration and maturation of development and test (DevTest) scenarios and solutions in the public and hybrid cloud space.
     
    I’ve been talking with folks and presenting on the movement of Dev/Test to the public and hybrid cloud for a couple of years now, and I have progressively learned a couple of things from those with which I have had great and sometimes very frank discussions. First, I learned that the definition of DevTest has expanded exponentially, with the movement to the different clouds. Second, I found that the terminology of “DevTest” just doesn’t fit a single threaded way of thinking any longer, such as “It’s just for developers.” Let’s take a closer look at these.
     
    Back when I was a young technician just starting  in the new world of IT, I was working primarily with programmers (they weren’t called developers or devs back then) who would sit in front of their green screens, writing huge applications with COBOL and RPG, or maybe writing shell scripts on a Unix system. They would test their code in different environments that were always on the same infrastructure that the production code was running (which we all know these days is wrong, right?). They didn’t have secondary hardware or OS installations to test against because it was just too expensive to accommodate and most of the code could not support that separation. 
     
    Fast forward the clock almost 30 years, and now the developers need to have logically separated and secure environments to provide accurate and meaningful testing of the code that is “born in the cloud” as well as those created on-premises. The next few years will bring a big push for developers to have their own self-service environments, extensive code portability and more secure isolation for their code. By utilizing container technologies, automation and rapid deploy processes for their code, more development groups will eventually become their own application development as a service. 
     
    DevTest solutions are also moving far beyond just testing code. Quality Assurance (QA) is already a substantial consumer of the cloud for their load, smoke and regression testing. I predict that there will be a huge advent across all roles within IT—and not just the ones of development and QA—that will take the plunge into the DevTest solutions. They will be running release scenarios on their rapidly and continuously updated OS versions, on all of the software-defined environments, while also adding software patch testing and issue mitigations. 
     
    Knowledge transfer, training and E-Learning also will increase the use of these landscapes over the coming years, with everything from purpose-built labs, globally connected classrooms and even enterprises expanding their hands-on learning management system (LMS) offerings to their employees and customers. 
     
    Finally, I would suggest that there will be an inflection point in the coming years in which the use of private, hybrid and public clouds for DevTest—and, eventually, production—will become transparent to the user to the point that, within the overall vision of what you need to accomplish, what cloud or combinations of clouds you utilize won’t matter any longer. Eventually, for infrastructure as a service (IaaS) at least, the cloud will go the way of hardware, which has largely become a commodity in the new evolution of the modern software-defined data center.
     
    Technology is moving incredibly fast these days, especially when compared to the days of old when I was coming through the ranks in IT. The DevTest solutions will continue to evolve, progress much faster and touch more people in technology—and even other professions—than ever before. Start building a solid DevTest design and implementation plan for whatever your business and IT goals may be, and invest in the solution for all of your IT functions. By embracing and utilizing what is available in the hybrid and public cloud space for DevTest, IT will be empowering more productivity and faster execution moving into 2019 and well beyond.

    — Mike Nelson

  • Edge Computing: Saving the Cloud from Ephemeral Data

    Edge Computing: Saving the Cloud from Ephemeral Data

    Edge computing is rapidly gaining momentum. Last week’s Linux Foundation news on the launch of LF Edge is one more sign of accelerating growth at the edge. What’s driving this sudden intense interest? It’s more than just the sheer number of edge devices or mounting concerns around interoperability and security. Pushing compute resources closer to the edge can save the cloud and networks from waves of ephemeral data.

    The concept of edge computing certainly isn’t new. In years BC (“before connectivity”), there were plenty of edge computing boxes. These featured single-board computers designed to specifications such as VMEbus, STDbus, PC/104, CompactPCI, AdvancedTCA and many others. Processing happened at the edge as data arrived. Ethernet connections made administration and results-sharing easier, but very few architectures relied on shipping all the data into the network.

    Of course, there was one big exception: a business model pulling all the data into the network. Telecom providers aggregated traffic from the edge into their core networks. As data traffic joined voice traffic, core networks grew with monstrous bandwidth and increased services. Core networks interconnected. Data traffic rose even faster, pushing the network into a cloud architecture. In years AD (“after distribution”), everything from the edge is now connecting to the cloud.

    Much of the increase in data traffic came from the shift to video content. Users expect higher resolution video programming with the same lag-free performance. Streaming networks and quality of service (QoS) implementations have made great strides in content delivery. 5G infrastructure rollouts in progress will keep mobile a strong downstream contender.

    What about upstream applications such as the IoT? Nearly the same terminology applies there. Devices gather data on the edge and transmit it to the cloud through a gateway. There are two key differences with most IoT applications, however. Real-time data may be lost if the streaming connection into the cloud is interrupted. Also, the fallacy of low bandwidth does not work at scale if all the data is transmitted. At some point—perhaps ten thousand, a hundred thousand, or a million or more sensors—an aggregate bandwidth problem develops.

    Just as in the BC age, it’s time to rethink shipping all that IoT data upstream, instead taking steps at the edge. Cisco Systems has studied data trends extensively, producing its white paper, “Cisco Global Cloud Index: Forecast and Methodology, 2016-2021.” The company points to the IoT ushering in the “yottabyte era” very soon. Cisco estimates that 220ZB of data was generated in 2016 and projects that by 2021, there will be nearly 850ZB from people, machines and things combined.

    Now for the interesting part: Cisco also estimates that as much as 90 percent of that data is ephemeral, short-lived data not useful to save. Even if only 10 percent of data is useful, it will swamp projected data center traffic by an estimated factor of four in 2021. Here’s Figure 24 from the Cisco white paper:

    Edge computing, or its close cousin fog computing, allows two things to happen: It can pre-process ingested data, ironing out protocols and format differences such that everything arriving at the cloud is immediately ready for algorithms. Any savings in the cloud from not shuffling data before computation are valuable, increasing processing and network bandwidth availability. Parts of an algorithm could easily be farmed out toward the edge, perhaps decimating or filtering data before shipping it upstream for heavy analysis.

    A bigger use for edge computing may be using algorithms to avoid shipping ephemeral data upstream altogether. Using generative models at the edge could make a huge difference in identifying useful data. Most of us have heard that no human can sit and watch hours and hours of surveillance video from multiple sources looking for one moment of a problem developing. Consider another example with an EKG monitor attached to a smartphone: While the patient is at home, at rest and unstressed, the EKG is in a perfectly normal range as learned by the application. Doctors are alerted when readings slip out of normal range, with raw data transmitted for observation if required. A similar example is waiting for a motor to fail while monitoring its operation.

    Both the LF Edge initiative and work happening in the OpenFog Consortium are creating specifications for edge computing. These initiatives are aimed at interoperable, secure architectures where cooperative processing mines data. If items of interest can be extracted efficiently from useful and ephemeral data at the edge, loads on the cloud and networks would be lighter. Edge computing will likely detect exceptions more quickly, bringing people in to look at what is going on faster. The result will be more scalable IoT applications with better chances of delivering value from all that data.

    — Don Dingee