Tag: devops

  • Morpheus Data Advances DevOps Across Hybrid Clouds

    Morpheus Data Advances DevOps Across Hybrid Clouds

    Thanks to the rise of multi-cloud computing, the challenges associated with managing DevOps are becoming exponentially greater. Most IT organizations are not likely to be 100 percent sure at any given time which application workload is running where.

    To address that issue, Morpheus Data has added a Cross-Platform Discovery module to its Unified Ops Orchestration platform that employs machine learning algorithms to determine not only what applications, virtual machines and containers have been deployed on-premises or in a public cloud, but also how much capacity, memory usage and power consumption each is using and their and overall performance.

    At the same time, Morpheus Data is adding integration with Github and Jenkins continuous integration/continuous delivery (CI/CD) environments as well as support for both Docker Swarm and Kubernetes clusters.

    Finally, Morpheus Data has added connectors to IBM Cloud, Upcloud and HPE OneView services and been certified as a ServiceNow partner. The Unified Ops Orchestration platform already supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform.

    Brad Parks, vice president of marketing and business development for Morpheus Data, notes that as IT environments become more distributed in the age of the cloud, new approaches to change management will be required. The Unified Ops Platform provides an opportunity to consolidate change management processes within the context of a single control plane.

    While more IT organizations are making use of multiple cloud services, most are managing each IT environment in isolation. Over time, the lack of unification of the control planes for each of those environments conspires to increase the total cost of ownership for IT. Morpheus Data is making a case of for unifying the management of multiple platforms running on-premises or in public cloud instead of requiring IT staff to master multiple management tools.

    That single management plane, Parks says, also makes it much easier for IT organizations to take dynamically employ multiple cloud environments. Price points for cloud services are liable to change at any moment, but it doesn’t necessarily follow that the same type of workload will continue to be deployed on the same cloud. At the same time, the characteristics of a workload may have evolved to the point where it doesn’t make financial sense to deploy it on a public cloud. A common management platform makes it possible to move that workload with the least amount of disruption possible.

    Most IT organizations today are concerned about getting locked into a cloud service provider. Being able to demonstrate an ability to switch between cloud service providers gives IT organizations an opportunity to negotiate cloud service contracts from a position of strength. Most cloud service providers are counting on the fact that the cost of switching from one provider to another is simply too high. Integrated DevOps processes wrapped around a common management plane, however, will make it clear to all concerned that the platform provider serves at the pleasure of the internal IT department, not the other way around.

    — Mike Vizard

  • DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    In this DevOps Chat, find out how the developers of Wolfpack (wolfpack.run) are saving over 50 percent in cloud costs by using ParkMyCloud’s cloud management platform.

    Though the cloud offers many benefits to app developers and others, controlling the costs can sometimes elude organizations big and small. Cloud sprawl can quickly lead to large cloud bills. In this chat, we speak with Jonathan Chashper, CEO of Wolfpack, about how his company got a handle on the cloud and is spending less than 50 percent of what it was paying before.

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

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 118815″ target=”blank” width=”200″ height=”200″]Chris Parlette
    Chris Parlette is the Director of Cloud Solutions at ParkMyCloud. Chris helps customers reduce their cloud waste and manage their hybrid infrastructures by drawing on his years of experience working at various software startups. From SaaS to on-prem, virtualization to cloud, monitoring tools to cloud management platforms, and small businesses to large enterprises, Chris has seen it all and loves helping drive improvements to IT management.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel of DevOps.com, and we’re here for another DevOps Chat. Today’s chat is actually a great behind-the-scenes look at ParkMyCloud and how an app provider named WolfPack is using Park My Cloud to really kinda get a handle on their cloud costs, their cloud usage and optimizing the cloud for their applications.

    That being said, let me introduce you to our guest for today’s podcast. Our first guest is the CEO and founder of WolfPack, and his name is Jonathan Chashper. Jonathan, welcome to DevOps Chat.

    Jonathan Chashper: Thank you, Alan. Thank you for having me.

    Shimel: Thank you. And then our second guest is from ParkMyCloud, it’s Chris Parlette, and Chris, I hope I don’t mess up the title, but it’s director of Cloud Solutions?

    Chris Parlette: Correct, yes. And thanks, Alan, for having us—appreciate being here.

    Shimel: Not a problem. So, guys, this is gonna be a fun one, I think. Jonathan, why don’t you give our audience a little background—what exactly is this WolfPack app?

    Chashper: Sure. So, WolfPack, we are—you can look at us as a connected vehicle technology focusing specifically on helping individuals move together. Think about how much fun it is to move as a group. Imagine you are, you know, maybe several families moving in a few cars. It’s a lot of fun, but there are two major problems—one, keeping everybody together, making sure people don’t get separated, don’t get lost. And the second one is actually communicating with each other while traveling and doing it safely.

    Now imagine you are now doing it on model cycles, which is the first niche we’re focusing on. So, we’re solving those two problems with WolfPack, and by the way, people can take a look at WolfPack.run-R-U-N-to see how it works. But generally, what we do is, we provide, with a turn-by-turn navigation, to every one of the people driving or riding, while providing a radar showing the location of everybody else.

    So, we actually make sure that everybody gets there without being killed, without being lost, without getting into a ditch, and making the experience much less stressful, and much more fun.

    Shimel: And that’s a good thing. But Jonathan, well, you know, WolfPack represents sort of this new—it’s not really new. I’ve seen them now for a couple years, but I call them these instant group type of applications where you can create a group on the fly and that group can have two people or 200 people or more, right? And this group then does something. In the case of WolfPack, you know, they’re on a run or a trip of some sort, and you have Google Maps built into it or underlying it and, you know, all of these things, and they’re great.

    The problem is, as you probably are well aware, is you never know from moment to moment, you know, what your load is gonna be, right? How many groups, how big a group, you know, what’s going on?

    And so, in resource planning, that can be a problem. Talk to me—

    Chashper: Correct.

    Shimel: —yep. Talk to us a little bit about what you’re doing with ParkMyCloud and how that’s helping you.

    Chashper: Mm-hmm. Yeah, so you’re absolutely correct. What you said at the beginning, it’s true. We can—our users can immediately generate groups, it can be, they can generate any number of groups. It can generate—any group can have any number of people. They can plan a ride which can be as short as 10 miles or as long as 1,000 miles, so you’re absolutely right.

    And so, when we’re building the system, obviously, it’s a cloud based system. We are on top of AWS. What’s important for us is that the development costs, being a startup, is being-you know, kept to the minimum. And so, what we did, we actually looked into ParkMyCloud, and with ParkMyCloud, we got to the point that we control our development costs very, very tightly. Generally speaking, when you’re using a server in the cloud, as long as you don’t turn it off, it still works and you’re still being billed for it. And if your development teams go home-say, they work 9 to 7 every day, they go home at 7. If the servers are off, you’re still paying for them.

    So, what we did with ParkMyCloud, we actually manage the up time of those servers, so we only pay for the time we’re actually using those servers for our development for our staging.

    The other good thing we’re having is that we actually have quite good visibility. True—a nice supporting feature, which I think is pretty new, where we can see very, very quickly, you know, when is our load high, what is actually being used, what is not being used, if anything needs to shut down. So, we can manage that very, very easily. And specifically, on the park management, it’s almost a file and forget. Once you set it up once, you never need to go back to it, and it just does it for you.

    Shimel: Got it. So, Jonathan, let me just be clear, I want to make sure we’re talking apples to apples. So, when you say, you know, you’re not using the server overnight or something like that, are you saying that, with ParkMyCloud, you can schedule your instances to close? So, in other words, I’m only gonna use this instance from 9 to 5, and at 5:00, retire that instance, close it out, don’t keep it on my billing account, and when I start up again tomorrow at 9, I’ll start a new instance with that same configuration and kind of pick up where I left off, or is it something else?

    Chashper: So, first, we need to understand that you can use ParkMyCloud on your non-production instances. Production instances obviously need to be up 24/7, so you don’t want to shut them down.

    Shimel: Yeah, you’re right—I should have said that. [Laughter] No one wants to shut down their production.

    Chashper: Yes. So, what I was referring to, I was talking about our development and staging nonproduction systems.

    Shimel: Mm-hmm.

    Chashper: Yeah, so that’s for that.

    Shimel: But are you actually—I guess what I’m asking, are you retiring those instances and firing up new ones the next day, or is it—

    Chashper: Oh, this is—yeah, so this is done automatically for us. That’s the beautiful thing about ParkMyCloud. We actually, once you set up the parking schedule, it will shut down the server, say, 5 p.m. today, and it will turn it on back tomorrow morning, say, 9 a.m. We don’t need to do anything. This is done for us automatically, and so you know, where the developers come back into the office, as far as they’re concerned, nothing changed, they just keep working.

    Shimel: That’s fantastic. Chris, I just want to confirm with you—those instances are actually, you know, it’s sort of like immutable infrastructure, right? Those instances are retired, done, and then re-fired up the next day?

    Parlette: Yeah, so what this is—and it’s not terminating the instances, it’s actually just stopping them and then turning the same ones back on. And the nice thing is about that, is that now, you know, as people are working on these servers, you know, if you haven’t fully gone with data, you know, not being stored on those servers, you know, as you’re working on these same servers over and over and over again, you know, we stop them and then start them right back up again. So, even if people like your finance department or your QA department maybe have some things, you know, spun up, we can actually turn them off to save on the CPU and memory costs, and then we just turn them back on again.

    Shimel: I got it. Okay, because I was gonna say, you know, I mean, the immutable infrastructure angle is great, but in this sort of circumstance, it’s not just a configuration of the server, it was the state of the data that you were working on, and how the heck would you re-create that every morning? [Laughter] But that explains it—got it.

    So, Jonathan, you know, so ParkMyCloud is making you guys a lot more efficient here in the cloud and your use of cloud resources. Have you been able to quantify a percentage savings or anything like that?

    Chashper: Oh, absolutely—most definitely. If I want to be, you know, conservative, I would probably say that we’re saving around 55 [percent]to 60 percent.

    Shimel: Really?

    Chashper: At least. Frankly, I think we probably save close to 70 percent. We’re really very tight. We really manage to do that in a very tight manner.

    Shimel: So, beyond just closing down and firing up the instances the next day, what are some of the other things you’re doing with ParkMyCloud?

    Chashper: Oh, so—well, for us, the first thing is reporting and notification. If something happens, we get notified, we can actually control what we get to be notified about. So, then we’ll get notification about maybe a server that needs to be shut down or something like that.

    Reporting is very important to us so you can see your usage, you can see what is up and what is down.

    Shimel: Got it.

    Chashper: One of the cool things we just started using is actually a mobile app. So, there is a mobile app on iOS for ParkMyCloud. People can download it at the iOS store. And it actually happened with me, I was at dinner, and we—my guys had to stay a little later, and we had to, what we call, snooze one of the parking, you know, schedules, and I just did that through the mobile app, I didn’t even have to go online.

    Shimel: Fantastic. Very cool. So, guys—look, 50 percent or better savings, all these other benefits is certainly nothing to sneeze at. I think anyone would jump at it.

    But, Chris, let’s dive in with you now a little bit, if we can. You know, we have an audience here of DevOps sort of folks from all over the world, right, who would love to save 50 percent on their cloud bill. How is ParkMyCloud working with these DevOps engineers and DevOps teams to realize those kinds of savings and efficiencies.

    Parlette: Sure, yeah. So, we work, you know, plug into a lot of DevOps processes and toolkits straightaway. I mean, that’s something that we do internally, and then, you know, we certainly have all of our customers, from large enterprises down to small startups, all doing this same kind of thing.

    And so, there’s a few different ways to do that. One of the big things about DevOps is automation, and so, we have a full policy engine so you can set up the policies to look at tags, to look at locations to different regions that these servers were in, naming schemes—all these different kind of factors, and you can automatically apply schedules and assign to teams and decide on different actions to take based on these policies for any new instances that you spun up. So, that’s one automated way.

    We also have a full API, so you could plug into DevOps tools like Atlassian, Bamboo or Jenkins so that these tools can kind of reach into our API, temporarily override schedules, change schedules—all this as a part of an automated thing.

    One of the other things about, you know, DevOps—not just automation, but also just thinking whole business, kind of a holistic approach to this thing—and so, we also have a full, a very easy to use UI. So, if your users are, maybe are a little less technical or you don’t want them to necessarily have direct access to a database console or Azure or Google consoles, this can kind of be sort of a proxy for that console so that other users can come in and manage their end servers. They don’t have to ask IT to turn things on for them. They can kinda manage their own servers and do all this, but you can decide who has access to what through this approach.

    So, there’s a couple different ways we plug into these teams and these processes so that users can get their best bang for their buck.

    Shimel: Got it, got it, got it. Now, so, Chris, when you talk about plugging into things like Bamboo or Jenkins, what you’re really—I mean, I just wanna make sure I’m clear. You can build sort of the ParkMyCloud—not sort of, but you can build the ParkMyCloud policies right into your CI/CD pipeline. Is that what you’re saying?

    Parlette: Yes, so if you do things like using tags, especially as instances are spun up or spun down, a lot of people say, you know, “Hey, I put a million tags on every instance.” And so, that’s what the ParkMyCloud policies can read off those tags and kinda decide on the actions based on those tags.

    And then, as far as things like—you know, specifically, if we were to talk about Jenkins or some other build processes, you know, you can have these environments built out and shut down. And then Jenkins, at the beginning of some sort of build process, can call into ParkMyCloud and say, “Hey, I need these servers up, and so I wanna override these schedules.” Spin ’em up, the servers are up, it does all it needs to do, and at the end, it just either shuts them down or, if you don’t shut them down, then basically, if you only did an override, let’s say, for two hours? At the end of the two hours, we’ll revert back to our original schedule, so that way you don’t have to remember to turn the lights out when you leave the room, right? So, we actually can shut things down for you.

    Shimel: Excellent. And Chris, give me an idea of—so, when you guys are engaged, I mean, with that kind of API, with that kind of integration into the DevOps toolset, you’re probably getting a decent view of how DevOps teams are using ParkMyCloud. And you’ve given us some examples, here.

    Are there any—I guess what I’m trying to ask, are there any special things that the DevOps people are doing that perhaps waterfall or other types of technologies are not doing? Is there commonality? Is it very easy to say, “Oh, these guys must be doing DevOps, because here’s, you know, what they’re doing?” Have you noticed any of that?

    Parlette: Yeah.

    Chashper: Alan, before Chris answers, maybe I can jump in and give a quick lead-in to this.

    Parlette: Sure.

    Chashper: Sorry, Chris—hope you don’t mind.

    Parlette: Sure.

    Chashper: Actually, one of the things I wanted to say is that we don’t have DevOps people at all, and one of the reasons we’re using ParkMyCloud is because we’re actually—we’re not DevOps people. We don’t know what needs to be done. We don’t speak, you know, Chef or any one of those guys.

    So—but the fact that we could actually use ParkMyCloud and then the user interface they provided us with, the web client, at least it did for us, went away, and everything is handled at that level. So, for us, that was a big, big move forward.

    Shimel: Yeah, no—and that actually is a great point, Jonathan. And Chris, I’m sorry we hijacked you here for a second.

    Parlette: No problem.

    Shimel: But the problem is, in today’s market, frankly, hiring people who have Chef or Puppet or Jenkins or, you know, DevOps skills sets is (a) hard to find, and (b) very expensive, right? And so, if you can deliver benefits like 50 percent savings on cloud usage or allowing some automation like this, it certainly is a lot easier. I don’t know of any engineering team that wouldn’t like that.

    But, you know, Chris, what do you see? I mean, are most of the people using the UI, or are they just you know, kinda going to APIs and stuff like that?

    Parlette: Yeah, and you know, as we get into larger customers, you know, it definitely is a mix of the UI and the API. The other change that we see, the mindset shift that we see from people is, especially as they’re moving from on-prem to cloud, a lot of people, when they’re used to—a lot of people, when they’re coming from a [Dog barks].

    Shimel: Hey, Jonathan, I think Chris might have shut off there for a second. Chris, you there?

    Parlette: Here we go. I’m back—I’m back. So, one of the things that, you know, as people are moving from on-prem to cloud, you get a lot of people who are used to leaving things on 24/7, because you know, on-prem, as things are left—you know, if you spin things up, it’s not an additional cost, really, to leave them on 24/7.

    And so, in this shift to the cloud, they have this shift of mindset where, if they’re being charged by the hour or it’s something that, you know, every hour that it’s left on is additional cost.

    Chashper: Yeah.

    Parlette: And so, when people are used to leaving things on 24/7, now the shift we have with people using ParkMyCloud, especially in an automated way, is to leave things off 24/7 and then kind of spin them up on demand. And so, that’s really where I think, you know, Jonathan and his team use that a lot, where things can be off, you know, turn on a schedule, but also just turn on on demand so, as the users have access to the UI and the API, they can turn things on on demand, as opposed to having to turn things off on demand.

    Shimel: Fantastic. Well, guys, you know, as I told you off mic, the time here goes really quick. [Laughter] We’ve already been on 18 minutes, beyond the 15 minutes I told you we would do, so we’re gonna need to wrap this one up right here. But first of all, Jonathan Chashper, CEO, Founder of WolfPack, it’s WolfPack.run is the URL, correct?

    Chashper: Yes, absolutely—thank you.

    Shimel: Thank you. Thank you for sharing with us today and giving us a little peek behind the kimono of how you guys are using ParkMyCloud. Continued success for any of our motorcycle riding friends or any group out there who—you know, I encourage you to check WolfPack out, it’s a pretty cool app.

    And Chris, thanks so much for sharing a little bit more, you know, a little behind-the-scenes look and a little bit more of a peek at, you know, ParkMyCloud and how it’s helping companies. Thanks for being on today’s DevOps Chat.

    Parlette: Yeah, Alan. Thanks for having me. I really appreciate it.

    Chashper: Alan—thank you very, very much. It was a pleasure.

    Shimel: Thank you, guys. You know what? We’re recording this right before Thanksgiving—have a happy holiday. Happy holidays to everyone listening! You’re probably listening to this after Thanksgiving, but it’s the start of the holiday season, so happy holidays, everyone.

    This is Alan Shimel for DevOps.com and DevOps Chat. Hope to see you soon on another chat, and have a great day.

    — Alan Shimel

  • Digital Transformation: How DevOps Could Have Revamped Toys R Us

    Digital Transformation: How DevOps Could Have Revamped Toys R Us

    The story you’re about to read and its recommendations are real; they contrast with what you have heard so far about digital transformation and DevOps implementation. Its objective is to convince you about that the time to go digital is now; it’s about transforming your business, not only IT; and to do it you’ll have to implement DevOps entirely.

    In September, Toys R Us, one of the world’s largest toys store chains, filed for bankruptcy protection. A better understanding of how disruption in the retail industry impacted the company would have helped to prevent its downfall and to reinvent its business model. For example, providing Toys 2.0 (a generic term referring to a new generation of toys built on cloud, mobility, IoT and AI technologies) gaming services could have helped the company survive.

    Shifting to Toys 2.0 demands a revolution in thinking, vision, practice and value that business leaders, CIOs and IT vendors haven’t done yet. They must forget the obsolete notion that technology and speed determine business success. Adopting paradigms that stress innovation and solve competitive constraints is the safest path toward fast and durable revenue.

    The biggest problem Toys R Us faced was the fact that consulting firms and IT vendors either didn’t understand the challenge as an industry disruption issue—or if they did, they improperly addressed it.

    Let’s clarify: To tackle your industry’s disruption, you must adapt your business model including the set of interactions, staff and skills, processes and practices, beliefs and values and infrastructure and tools used across your company to generate revenue. Industry disruption is the challenge, and DevOps through its many assets is the unique business capability companies need to quickly transform and win their digital battles.

    The problem, as Alan Shimel, founder, CEO and editor in chief of DevOps.com, puts it:

    “While so many companies have already started to use DevOps or planning to use DevOps and related methodologies soon, there is only a small percentage of companies that are end-to-end DevOps. This means there is still tremendous opportunity in bringing DevOps to market.”

    How should have Toys R Us leveraged DevOps to tackle its industry’s disruption? Why did investing in that global digital e-commerce platform prove insufficient? How well did they transform their business model? How would have implementing DevOps 100 percent helped to overcome Amazon and Walmart competition?

    The principles, ideas, practices and solutions in this article are part of a case study we developed at ITaaSNow to see how to help companies facing similar challenges.

    What is DevOps?

    Alan, who is a major contributor to DevOps, is right: Only a small percentage of companies have fully adopted it. DevOps is much more than the automation toolchains consultants and vendors talk about. If they want to help lines of business survive and keep their job, CIOs must get a grasp of DevOps’ business facets.

    So, what is DevOps? Why do I think, it would have saved Toys R Us from digital downfall?

    DevOps Beyond the Operations Automation

    From my experience implementing it, DevOps is a business capability that seeks to optimize business operations (versus the sole IT operations). It provides companies with four competitive advantages needed to meet the digital business competitive challenges:

    1. Enterprise collaboration
    2. Business agility
    3. Short time-to-value
    4. Innovation culture
    Figure 1 – DevOps Overview

    As the picture shows, DevOps is a set of concepts aggregated around the notion of value stream to form a digital business management capability. It’s structured around four stages that format the company’s interactions and workflows into a powerful digital business management capability. These stages include:

    • Plan & Measure – addresses strategic watch, service prioritization and revenue generation through innovation portfolio management practices and infrastructure.
    • Develop & Test – takes advantage of agile and lean practices and infrastructure to ensure innovations design, development and testing.
    • Release & Deploy – leverages continuous delivery practices and infrastructure to timely deliver the right innovations to the right markets.
    • Monitor & Improve – stresses continuous improvement to guarantee not only premium customer experience but also customer value.

    Four business value catalysts are used to act as revenue generators:

    • Culture & Values
    • People & Skills
    • Methods & Practices
    • Tools & Infrastructure

    As you can see, DevOps transcends application development issues; it covers the entire business life cycle.

    DevOps Framework as a Facilitator of DevOps Implementation

    So, what is a DevOps Implementation framework?

    Concretely speaking, it’s a bundled DevOps platform combining managed PaaS infrastructures and optimized value streams to help companies boost their digital business:

    Figure 2 – DevOps Implementation Framework

    The platform seeks to help businesses implement DevOps end to end and builds on three principles to guarantee digital profits:

    1. Innovation as the revenue driver – It’s the belief that business can resist the competition imposed by technology companies such as Apple, Google, Amazon and Facebook when they use innovation to keep customers loyal, attract new ones and generate revenue.
    2. Value stream agility as the foundation of market responsiveness – It’s the demonstrated notion that companies are market-responsive when they rely on agile and lean value streams.
    3. Managed cloud as the catalyst of business performance – It’s the proven idea that when companies are focused on their core business, they innovate and offer superior customer experience.

    The 5-Step Digital Transformation Blueprint

    The 5-Step Digital Transformation Blueprint makes DevOps implementation fast and easy. As illustrated, it’s a comprehensive business transformation framework I developed to help clients with their digital transformation initiative:

    Figure 3 – The 5-Step Digital Transformation Blueprint

    It’s an integrated and inclusive approach to business transformation that involves the company’s relevant contributors. It structures the transformation effort into a five-stage transformation journey:

    • Digital strategy: In this step, the transformation team uses tools like the SWOT analysis matrix to help business and IT executives understand the changes in the disrupting industry along with the impacts on the company’s business model.
    • Value stream: In this step, the transformation team uses tools such as the value stream mapping to identify the required changes and get business and IT executives agree on the company’s future value stream. Interactions, staff, skills, processes, practices and tools are at the heart of the discussions.
    • Digital platform: In this step, enterprise and solution architects work together to identify and implement the technology and tools selected to support activities in the value stream.
    • Digital organization: In this step, a panel of business and IT users at the operational and executive levels experiment the new digital business model under actual business conditions. The tested digital business model is then deployed as the new digital organization.
    • Digital business management: In this operation phase, the value stream and the digital infrastructure are extensively used to run the business.

    How Chief Digital Officers Set Up Top Digital Businesses

    It would be remiss on my part not to recommend the online digital transformation course that gives DevOps practitioners—executive and operational from both the business and IT—the insights about implementing DevOps as the foundation of digital business.

    “How Chief Digital Offers Set Up Top Digital Business: Establish DevOps as the Foundation of Your Digital Business” is a 15-module course that offers concise, practical and powerful tips to help practitioners learn and apply strategies and tactics to effectively plan, monitor, facilitate and lead business transformation including IT to digital.

    Analyzing Amazon and Walmart Disruptive Impacts to Spot Guidelines for Reinventing the Company

    Many bankruptcies happen because business leaders don’t take the time to understand their industry’s disruption and the impacts on their overall business.

    The reality on the ground is, industry analyses and competitive strategies are either overlooked or totally ignored. Understanding the toy industry’s disruptive effects would have helped to identify Toys R Us’s transformation as the safest solutions to avoid bankruptcy.

    DevOps implementation framework makes the difference, it sees DevOps as the foundation of digital business success. It considers industry and competitive analyses essential steps of the DevOps transformation initiative. Figure 4 outlines the outcomes that resulted from our industry analysis:

    Figure 4 – Toy Sector’s SWOT Analysis

    As illustrated, it was shown that Toys R Us should have exploited Amazon’s vulnerabilities and take advantage of the technological opportunities to reinvent itself as a Toys 2.0 gaming service provider. These vulnerabilities include little product differentiation while technological opportunities refer to the new toy generation built on cloud, mobile, IoT and AI technologies.

    The company’s strengths—reputation, longtime industry presence, brand equity—combined with the cost savings resulting from managed cloud adoption would have not only simplified its transformation but also challenged Amazon on costs.

    Changing the Value Stream to Establish Innovation and Invent the Company’s Digital Business Model

    Business leaders don’t take the right transformation decisions because they lack insights into the changing competitive environments. Aggressive marketing and sales campaigns supporting short-term financial gains. Toys R Us failed because it bet on its debt reimbursement at the expense of its business model reinvention.

    A DevOps implementation offers a value stream mapping framework that not only facilitates innovation culture implementation but also speeds up digital business models development.

    Figure 5 – Value Stream Mapping, Agile, and Lean

    The objective of the value stream mapping I performed was to outline the features of work environments that take advantage of DevOps Three Ways to equip the company with the competitive advantages needed to resist Amazon and Walmart. The following lines summarize the outcomes.

    Implementing DevOps Flow Principle to Defeat Amazon and Walmart on Innovation: The value stream mapping recommended to leverage Agile and Lean principles to properly implement the flow principle and defeat Amazon on its little product differentiation. The Agile’s features to stress included collaboration and prioritization while focus on people engagement and customer value were the Lean’s benefits to emphasize. Their combination were likely to not only foster innovation culture but also accelerate time-to-market and time-to-value.

    Implementing DevOps Feedback Principle to Guarantee Superior Customer Experience: As to the feedback principles, the value stream mapping recommended to use Lean’s value stream assessment and Agile’s review mechanisms. The objective was to institutionalize continuous improvement practices as a means to ensure superior customer experience.

    Implementing DevOps Experimentation and Learning as the Foundation of the Innovation Capability: As to the experimentation and learning principle, the recommendation was to take advantage Agile’s prototyping and learning curve-lessening features to institutionalize innovation and risk-taking cultures. They were likely to not only help the company challenge its competitors on innovation but also ensure durable revenue and customer loyalty.

    Enabling the Value Streams with Managed PaaS Services

    Using technology ingeniously to boost business activities is clearly one of the keys to succeed in the digital business. Today’s DevOps-timid approach focused on speeding up IT operations alone not only is ineffective, but it also doesn’t make sense. It’s the entire value stream that needs optimization, not just IT.

    The findings of the digital platform assessment I performed, showed as illustrated, that the global e-commerce platform wasn’t enough to compete against Amazon and Walmart. The company was at the embryonic stage of digital transformation maturity practices:

    Figure 6 – Toys R Us Possibly at the Embryonic Stage of Digital Transformation Maturity

    The findings suggested that using technology to innovate or creating the operational conditions to cut cost, accelerate time-to-market and be responsive to market opportunities were either overlooked or improperly addressed.

    Using a digital platform engineering framework allowed me to design in a record time the following architecture:

    Figure 7 – Possible PaaS Platform for Toys R Us

    The digital platform would have built on two cloud services supporting the value stream: managed software as a service (SaaS) and platform as a service (PaaS). Let’s discuss them.

    How Managed SaaS Services Would Have Helped to Fix the Cost Leadership and Business Agility Issues

    SaaS services would have supported the Plan & Measure stage. In addition to supporting varied management activities, it would have provided two fundamental tools that possibly could have enabled the Toys 2.0 strategy: customer relationship management (CRM) and innovation management portfolio. CRM tracks, measures and improves customers’ experience, keeps them loyal and guarantees revenue. Innovation portfolio management identifies innovation ideas, supports their implementation into digital services and monitors generated value. It gives the company opportunities to disrupt and control its industry.

    The on-demand and metered billing features of SaaS services would have allowed Toys R Us to get the needed software in record time while enabling time-to-market, time-to-value and responsiveness competitive advantages.

    How a Managed PaaS Platform Could Have Helped to Address the Express Delivery Issue

    PaaS services would have supported activities covering the Develop & Test, Release & Deploy and Monitor & Improve stages. In addition to providing the technologies needed to implement Toys 2.0 gaming services, it would have built on microservices to set up the automation tool chain and accelerate innovations development and delivery.

    Wrapping Up

    The recent IT innovations are disrupting several industries and expanding the digital economy. To avoid troubles, businesses must urgently start their digital transformation. Toys R Us, Sears and many others learned it the hard way.

    It’s urgent to understand that the digital transformation of your business isn’t only about migrating your IT to the cloud, implementing automation tool chains or deploying artificial intelligence tools across the company. It’s primarily about transforming with a strategic mindset your company’s business model from the ground up.

    Digital transformation is a complex process that engages the entire company, and requires specific methodologies, practices and tools. I renew my recommendation to take the online course, “How Chief Digital Officers Course Set Top Digital Businesses“—you’ll get from it the practical vision, approach, processes, practices and tools that’ll help you create the conditions for successful digital business with DevOps.

    — Philippe Abdoulaye

  • Mastering the Art of Cloud Migration

    Mastering the Art of Cloud Migration

    Cloud computing has come a long way over the years. Yet, only a few enterprises have managed to master the art of cloud migration. The secret to a successful migration lies in a well-defined, phased and iterative approach that not only streamlines the process but also accelerates the outcome. Here is one road map to assist others in transforming their migration journey:

    Phase 1: Plan

    Benjamin Franklin once said, “If you fail to plan, you are planning to fail.” Planning thus becomes the most critical part for a cloud migration program. Key focus areas in this phase include program management setup, portfolio analysis and cloud architecture and operating model layout.

    • Program management setup: The program management office (PMO) plays a major role in managing all aspects of the planning phase, from facilitating strategy building to program governance and benefits realization. The PMO ensures strong leadership commitment, sustained change management, program strategy alignment, rigor in project execution and decision-making governance.
    • Portfolio analysis: Analyzing the application portfolio helps in providing adequate representation of applications in scope. Application dependency information helps plan the sequence of application migration. It further pushes the business case for enterprise cloud migration.
    • Cloud foundation and operating model layout: The cloud foundation is comprised of landing zones. A landing zone is a standard set of secured cloud infrastructure with built-in policies, standards, guidelines and centrally managed services. Creating a strong foundation through landing zones is crucial for a scalable and sustainable enterprise AWS cloud model. As cloud computing becomes the paradigm for delivering business, technology operating models need to evolve and add more cloud-centric capabilities. A cloud operating model is the framework for putting core elements together in a more agile, productive and valuable way.

    Phase 2: Assess

    During the assessment phase, applications are analyzed in detail for future disposition. A cloud architecture and cloud operating model help lay the foundation for migrations. Consider the following:

    • Macroanalysis: Macroanalysis of applications, leveraging a proven cloud readiness and assessment framework based on business value, IT efficiency and cloud suitability ensures a clear migration road map. It also identifies enterprisewide concerns around security, networking, technical, operational, organizational, regulatory and financial.
    • Microanalysis: With the macroanalysis already performed, it is time for the deep dive. Microanalysis facilitates the understanding of current state architecture and defines cloud architecture based on patterns developed during macroanalysis. It concludes with the preparation of the detailed migration plan and effort estimates.
    • Cloud foundation and operating model design: The design should adhere to enterprise security and networking policies. Account and VPC structure needs to be designed based on cost allocation, resource management and ownership and security and compliance isolation. People, process and technology are the core elements of the cloud operating model. These should evolve to achieve cloud operating model goals, thereby increasing the value for the business and operations. People skills and experience are geared toward becoming more cross-functional, spanning a wider range of service components and use cases. Processes are then realigned around services instead of technologies, while tools and technologies are selected for effective implementation and automation of processes.

    Phase 3: Migrate

    During this phase, foundation cloud architecture and operating model are implemented, and the first set of applications identified as quick wins are migrated. The set should include a varying complexity of applications across different business units. Also, during this phase, it is important to take a proactive approach to change management. Consider the following:

    • Cloud foundation and operating model implementation: This step enables setting up landing zones including accounts, VPC, network connectivity, IAM Roles, policies and deployed workflow. Shared services and tools are also provisioned. In the cloud operating model, key processes are rolled out and teams are mapped to the new cloud-centric roles. This is followed by rolling out of subsequent processes leveraging the key learnings from the existing implementations. This ensures seamless integrations with current systems through the installation of selected tools.
    • Initial migration: The first set of applications is migrated as quick wins. The successful migrations help understand the portfolio and add to the confidence of the applications team. Importantly, it also lays down the foundation for repeatable migration patterns.
    • Change management: Effective change management is pivotal to the success of a cloud migration program. Change champions are involved to ensure co-creation of the future road maps and smooth cultural shifts. Continuous knowledge sharing and training is performed to evolve skills and include them in the transformation journey.

    Phase 4:  Scale

    After initial application migration, it is time for enhancing scalability and accelerating the cloud migration journey. While shifting the focus to scalability, it becomes important to keep a tab on cost and security. Consider the following:

    • Large-scale cloud migration: Harnessing the migration factory model is the best approach to target large-scale migrations. Based on the migration pipeline and supported by best-of-breed tools and specialized core/flex teams, it brings reliability and efficiency to the process.
    • Operating model optimization: Costs can escalate quickly. It is therefore essential to keep a check on it and optimize through policies, processes and moni­­­toring. It requires streamlining financial management by ensuring standardized tagging on all cloud resources.
    • Hybrid cloud model optimization: During this transition phase, both on-premises and cloud models are managed. The cloud model is further enhanced and optimized based on new services and tools.

    DevOps Automation – The Key Ingredient

    Cloud migration is a great time for enterprises to rethink their operational processes and improve the efficiency in managing and administering their portfolio. DevOps automation helps address the needs of a successful cloud migration while improving the operational efficiency of the services. This includes both infrastructure and application deployment automation. Additionally, standard templates and scripts significantly accelerate the buildout of future environments. DevOps also brings a number of business benefits including repeatability, auditability, significantly lower deployment risks and faster iteration cycles—all crucial to improved operational excellence, better security posture and improved competitive advantage.

    About the Author / Aarti Sahni

    Aarti Sahni is a technology leader with a wealth of experience in applying technical and operational expertise to create business value. Aarti’s expertise spans Practice Management, Cloud Computing, Architecture, and Program Management. In her current role at Virtusa, Aarti contributes to business growth by leading a number of pursuits and practice competency development. She also oversees several cloud programs ensuring desired outcomes for clients. Aarti has led a number of large transformations including cloud migrations, DevOps and cloud operating model to drive revenue, reduce costs and increase productivity. Aarti received a Master’s in Computers Application from Delhi University and completed an Emerging Leader Development Program at Columbia Business School in New York. Connect with her on LinkedIn.

  • Understanding the Mobile DevOps Process

    Understanding the Mobile DevOps Process

    In today’s current technology scenario, mobile app developers are always on the lookout for the latest IT innovations to stay on the competitive edge. To make the process of developing mobile apps more efficient, mobile service providers have adopted mobile DevOps.

    Mobile app development adopts the latest trends, technologies and tools for developing intuitive mobile application across different platforms as well as industry verticals. There are many mobile developers who are experts in the development of hybrid and native mobile applications across the platforms for end-to-end mobility, such as iOS, Android and Windows. Service providers aspire to achieve the business objective of the clients through leveraging people, processes and the latest technology.

    Why Mobile DevOps

    There are so many discussion and articles on mobile app development and how mobile DevOps practices could be integrated, adopted with existing processes and even how to use efficient resources that are beneficial for organizations. However, little has been said about why mobile DevOps could make a difference to companies that strive to enable their IT, development and operations to integrate with business goals.

    DevOps is vital for modern app development and delivery. However, leaders in the mobile application development and IT operations should address the unique collaboration, testing the release and analytics needs of mobile DevOps environments.

    Mobile DevOps for a Mobile Apps Developer

    The mobile DevOps discipline needs important business and technical decisions to be usable and to provide value for organizations. To get all critical pieces together and allow continuous mobile DevOps workflow, potential problems and bottlenecks should be identified. Nevertheless, mobile DevOps has its pros, as well.

    For a mobile developer to win the loyalty of mobile users, it must ship the right applications to the right customer at the right time. One has to continuously ship high-quality software and continuously listen and learn from users, providing them features before they know that they want them. Agile development methods are not enough; to win in mobile application, a developer needs mobile DevOps. It combines great automated tooling with a “continuous everything” culture.

    The Pros of Mobile DevOps

    Mobile DevOps has a number of advantage, including:

    • Shortens release time. DevOps, it’s been said, is about collaboration across teams, something that was not managed properly with the old waterfall practices. Actually, mobile DevOps is more than that. The simplified processes, when operations and development come together, could enable organizations share information between the teams and others and considerably shorten the time from the design-development phase to the actual release. Iterative cycle during development enable more frequent deployment of code, get new regressions tested, verified and released faster than regular phase-by-phase process. Mobile DevOps offer a faster path of fixing occurring problems with the product. Once enhancements and features implemented for each build are done, continuous integration with the right test setup provide a faster solution to problems.
    • Enables creation of better applications. More time spent on making new features, advantages and benefits for users simply are enabling the creation of better user experiences. User experience is the true differentiator today in the competition of the mobile apps popularity. Only those that enable delivery of experiences that users expect could remain in the competition. One of the most important things in doing DevOps is enabling instant feedback and reporting, transparent visibility to development and regression testing is paramount. This provides the mobile team an easy way of troubleshooting issues faster and fix, refactor and optimize user experience.
    • Saves time and make use of efficient resources. Faster features delivery, new build and updates are achieved when operation environments such as development, staging and production are stable and the operating environments work easily for development. This itself makes the whole mobile app development process more productive and helps maximize business advantages. One enabler of mobile DevOps is automation. Automation is available from source code management to testing and development tools and further to actual mobile app monitoring in production.
    • Provides multiple tools options. There are hundreds of thousands of tools that mobile applications are developed with daily. For any kind of feature, there should be a tool that could help build, test and deploy a certain part or feature of the app. Nonetheless, for good reason, some tools are used commonly by the mainstream. Most of the tools used and mobile DevOps processes that establish mobile DevOps core facilitate continuous integration, continuous release as well as continuous deployment. Part of the process is app release automation tools, which help up packaging and deploying app from development to production using automation. These tools help mobile DevOps flow to produce capabilities for implementing continuous delivery for even huge number of releases. Release management tools enable organizations to plan and to execute releases, offer a single collaboration portal for all stakeholders and provide traceability for a release and its components across all the build and delivery pipeline stages.
    • Could dodge inefficiencies and bottlenecks. The major idea behind Mobile DevOps is to make things transparent and efficient, boost internal communication and help in building better products or applications. When mobile DevOps practices, processes and tools are in line, several bottlenecks and inefficiencies could be avoided, such as:
      • Inconsistent development environments
      • Stability and maturity of workflow
      • Manual interventions
      • Lack of operational practices
      • ‘Old way’ and ‘new way’ integration
      • Competing/misaligned procedures and lack of ownership
      • Old-fashioned or manual testing process.

    Mobile DevOps is capable of transforming how an organization handles the development process for the better. It is no wonder  it has become the way of the future for mobile organizations. The DevOps approach principle puts emphasis on people and culture above tools and processes; thus, bringing business owners intimately to the design process can boost the success of the process. Organizations have to embrace a combination of collaboration and integration tools from both parties. Seamless interaction unlocks full benefits of the method and could ultimately contribute to overall business and operational success.

    About the Author / Drumit Shukla

    Dhrumit Shukla has been working as Business Development Manager in a software development company named TatvaSoft since 5 years. He is profoundly skilled and well experienced in providing software development services on various technologies ranging from Microsoft .NET to JAVA, Salesforce, BizTalk, SharePoint, PHP, Open Source, iOS, Android, Pentaho and more. Connect with him on LinkedIn.

  • No-Ops: It’s Been 5 Years

    No-Ops: It’s Been 5 Years

    As I hinted in this post, the state of no-ops is not anywhere near no-ops for most use cases. The closest we have today would be software as a service (SaaS), which handles the majority of operations for us, but still requires some interaction by operations staff.

    The next closest I can think of is the extreme form of hosted. My company uses a hosting provider to handle its website and blog, and the provider does a ton of the heavy lifting. But it would be a fabrication to imply that this mean no operations were performed. The simple fact is that backups, software updates and user management all are in our operational ballpark.

    About That Five Years …

    Why did I mention five years? That’s when the “No-op flame war” erupted. PCWorld has a pretty good summation of it, with links to the blogs in question. The short version is Netflix claimed No-Ops (later it became pretty clear the company just renamed a DevOps-reduced operations group), and Etsy responded with, “That’s because you’re doing it wrong.” Then people jumped on the “no-ops is not a good phrase” bandwagon, and it was … fun to watch.

    But Again, That’s Not the Point

    We too often get caught up in buzzwords. What we want to do is reduce operational overhead significantly per app. This reduces time to delivery, and it frees up time to work on new apps that are useful to the business or spur new business. If we can operationally manage three times the applications because we’ve reduced operations overhead, then we have time to do more. One of the things we haven’t done real well in the past is phase out technology. Perhaps with the free time we could reduce the operational overhead caused by five different solutions to the same problem across our application domain, offering even more time to work on new functionality or product lines.

    Don’t Get Sucked In

    I would argue that both Netflix and Etsy were “doing it right.” You start from where you are, and you streamline both operations and development. You start to ignore boundaries where the ROI is measurable, and you make your environment better/stronger/safer/more agile, whatever the business needs. And then you iterate again. Who cares what you call it?

    No No-Ops

    If No-Ops is coming, it is a loooonnnnggg way off. That’s okay. Because we are improving. You may iterate through improving a zillion times, with different goals each time, implement advanced monitoring and recovery, and wake up one day to realize that you’ve reached “No-Ops.” But as long as you are improving the cycle time/maintainability of the environment you work in, worrying about no-ops is pretty much a waste of time in the current environment.

    But You Knew That

    Here at the end, I’m kind of repeating what most of you already know. But when the hype hits, it doesn’t hurt to have a reminder. Most of you are keeping your business running and cranking out new apps as you’re able, and doing so at a faster pace than you were five years ago while others were arguing about no-ops. So keep doing that. Push Agile/DevOps further on each project. The more time you free from repetitive work, the more you have for doing/learning cool new stuff. So keep cranking, and one day you’ll have apps that are near no-ops.

    — Don Macvittie

  • LightStep Unveils APM for Microservices

    LightStep Unveils APM for Microservices

    Various forms of application performance management (APM) platforms have been around for some time. But with the rise of microservices many IT organizations are discovering that legacy APM platforms were not designed to handle the volume of software modules or the rate at which those modules are updated. But LightStep, a startup founded by former Google employees and flush with an additional $29 million in funding, is positioning itself as the first APM written from the ground up for microservices environments.

    LightStep CEO Ben Sigelman says regardless of where software modules and components get deployed, LightStep [x]PM is capable of monitoring and troubleshooting performance issues across all web and mobile clients, monoliths and microservices.

    Most of the demand for LightStep [x]PM, he says, is being driven primarily by microservices based on containers such as Docker. But the APM platform itself can support both microservices and legacy monolithic applications. That creates an opportunity to rationalize APM platforms as organizations make the shift to microservices while continuing to need to support existing legacy applications running in a production environment, Sigelman says.

    Twilio, Lyft, Yext, GitHub and DigitalOcean are already using LightStep [x]PM, which traces its roots back to Dapper, an always-on distributed tracing system that Sigelman developed at Google in production environments. A decentralized architecture enables LightStep [x]PM to continuously analyze 100 percent of transactions across all services. A statistical engine is then employed to detect anomalies, which the APM can then record and replay as part of an end-to-end tracing capability based on OpenTracing, an open API standard co-created by Sigelman and others that has now become a project administered by the Cloud Native Computing Foundation (CNCF).

    Other capabilities embedded within LightStep [x]PM include support for service mesh and load-balancing technologies such as Envoy, linkerd, nginx and haproxy.

    With every new era of enterprise computing, a contest occurs between startup companies such as LightStep and incumbent providers of technology platforms. LightStep is clearly trying to fill a void before incumbent providers of APM platforms can add support for microservices. Incumbents occasionally rely on their own organic efforts to upgrade their platforms, but more often they buy a startup company and then spend several years trying to unify disparate code bases.

    Of course, there are many organizations that are just beginning their DevOps journey. Many of the them may not have any kind of APM platform in place. Most tend to be cost-sensitive as well, so offerings based on open-source code tend to have greater appeal.

    However the APM wars play out, it’s apparent they are about to enter a new phase. The winners and losers of those wars will be determined by DevOps teams rather than C-level IT executives trying to impose a framework from on high. After all, if IT organizations have learned anything in the last few years, it’s that DevOps tends to have a more lasting impact when it comes from the bottom up.

    — Mike Vizard

  • Micro Focus Unfurls Functional Testing Service

    Micro Focus Unfurls Functional Testing Service

    The merging of software assets from Micro Focus and Hewlett-Packard Enterprise (HPE) that occurred earlier this year included StormRunner, a series of load- and performance-testing tools. Micro Focus recently extended that portfolio with the introduction of Micro Focus StormRunner Functional, a suite of functional testing tools delivered as service that can be employed to test applications running on any browser, operating system or mobile device.

    Shane Evans, director of product management for application delivery management for Micro Focus, says StormRunner Functional spans a variety of automated tests addressing unified functional testing (UFT), UFT Pro and Selenium browser testing tools that include elements developed by both HPE and Micro Focus. The Micro Focus StormRunner Functional Testing service also includes pre-built integration with Google Analytics, Micro Focus Octane, GIT and Jenkins to streamline the testing process.

    Interest in automated testing has increased substantially in the last few years, says Evans, because developers are under more pressure than ever to roll out new applications and associated updates faster. Unfortunately, most developers don’t have the time required to test applications themselves, or there is simply not enough money in the budget to hire quality assurance teams to test every element of an application. Micro Focus StromRunnner Functional provides an alternative approach using a set of testing tools that have been widely employed across the enterprise for decades, says Evans.

    Evans notes Micro Focus is pursuing a comprehensive approach to application delivery management spanning everything from testing tools to application lifecycle management. Micro Focus is making the contention that most DevOps teams are a lot more interested in getting access to the results of a test than managing the actual testing technologies themselves, says Evans. In addition, advanced analytics and machine learning algorithms, which now are standard elements of testing process, require access to massive amounts of data to be effective. That data is a lot easier to aggregate in the cloud using SaaS applications than in an on-premises environment. In fact, Evans says, those requirements are among the factors driving a wave of recent acquisition across the application testing sector.

    Arguably, the biggest testing challenge organizations now face is moving away from processes based on IT Information Library (ITIL) guidelines to a more DevOps-centric process, under which continuous testing is more embedded within the application development process, Evans says. Functional testing is only one element of the testing process, but it has become more critical as end users become less forgiving of substandard digital experiences inside and out of enterprise IT environments. Regardless of who inside the organization is responsible for testing applications, the expectation now is that every application experience inside the enterprise will be on par with a consumer application experience.

    — Mike Vizard

  • Cuba Embraces DevOps, Despite Infrastructure Challenges

    Cuba Embraces DevOps, Despite Infrastructure Challenges

    A few weeks ago I had the pleasure of speaking at the second DevOpsDays event in Cuba alongside some great technologists from across the United States, Europe and Latin America. The conference was held in a beautiful hotel in Varadero overlooking a marina right by the beach. Varadero is approximately two hours by car from Havana.

    The first thing I noticed is that Cuba is full of anachronisms. This became evident as soon as I walked out of Havana Airport and realized that the whole “they have some old cars” thing was real. It was fascinating to see that every single car was pre-1950s, some perfectly maintained with great paint jobs and others in worse condition yet still capable of doing their core job as a mode of transport.

    Talking technology in Cuba was eye-opening, to say the least. Do not expect to have 3G or 4G data on your cellphone. Do not expect to have WiFi in most hotels (you can purchase prepaid internet credit, but the speed will be slower than what you are used to) and definitely do not expect to have WiFi in a private home. These are luxuries.

    But here’s the surprising part: There are companies in Cuba with fully automated CI/CD pipelines achieving 10 to 12 deployments per day and solving real problems, such as the team working under Anesto del Toro at Datys. Cuba even has its very own Docker Captain, who gave a superb demonstration on the value of Docker in front of the DevOpsDays audience.

    Now let me remind you, these guys are not working with stable internet connections and they manage to get the job done on a daily basis.

    Why am I Rambling on About Cuba?

    Engineering is about solving problems. No matter how big or small, it’s about looking at a problem and finding the solution. Now, this is part of Cuban life. If something is broken, they don’t throw it in the trash and buy a new one; they fix it. Their 80-year-old car breaks down two hours outside of town? They get out of the car to fix it and—take my word for this—their friends, family and neighbors will come outside to fix the problem, too. This creates a mindset of solving the problem at hand without fail. This is easily demonstrated when you talk to Cubans about software development: They won’t say they are a Python engineer, a Java engineer or any other choice of language—they are software engineers who understand how development works as a whole. They will use the language required to get the job done to the highest standard.

    Like everywhere else in the world, there were huge differences in levels of DevOps adoption between the various organizations in the country. In contrast to the companies mentioned earlier, there also are organizations that have only just heard of these methodologies or are now considering setting up their first CI pipelines. Like many of us, they are still figuring out how to solve their technical debt and modernize their IT Infrastructure, but the key point is that the stakeholders, C-level executives, junior engineers and everyone else in between want to learn. They are open-minded to the principles of DevOps. Every person in the room at DevOpsDays Cuba was focused and listening to what we had to say. This excited me as a speaker and everyone else in attendance. We could see people who really did want to change and transform the cultures within their technology teams and overall businesses to start adopting these modern and proven practices.

    The journey ahead is a long one. The infrastructure challenges remain in place and there is much to be learned, but it was great to see such positive energy and eagerness to adapt. I want to thank everyone who attended DevOpsDays Cuba for making it such an amazing experience. An even bigger thanks to the organizers Enrique Carbonell, Rudy Gevaert, Yadier Perdemo, Manuel Oliver, Mike Rosado, Manuel Morejon and anyone I’ve missed. The event couldn’t have been better and it was a genuine pleasure to visit Cuba, I hope to return soon and reconnect with as many of you as possible!

    About the Author / Conor Delanbanque

    conordelanbanque

    Conor Delanbanque has been recruiting and leading recruitment teams in the DevOps space for the past few years. As well as being exclusively responsible for growing some of the most innovative DevOps & SRE teams in the US and Europe as an external consultant and recruiting partner, Conor also founded the Future of DevOps Thought Leaders Debate, sponsors DockerNYC Meetup on a regular basis and co-hosts ServerlessNYC. You can tweet him at @ConorDevOps, find him on LinkedIn or at events, expos and writing articles on DevOps.com.

  • Cloud Services Demand Security Up the DevOps Stack

    Cloud Services Demand Security Up the DevOps Stack

    In the era of soaring use of public cloud by companies, software delivery is moving away from an on-premises install approach to a cloud-based subscription model through software as a service (SaaS).

    Customers expect a lot when it comes to SaaS products and services. Whether they are investing in SaaS-first offerings or shifting workloads to cloud-based providers, companies no longer have upfront costs for hardware and related software or a reliance on costly labor to install, manage and secure it. They expect software that is easy to launch, upgrades that are unobtrusive and feature-rich and limitless scaling to meet their changing business needs.

    When it comes to security, the cloud-based subscription model significantly changes the paradigm of how software security should be treated. Fortunately for many cloud providers, customers trust that a strong foundational security and privacy posture has been built into to the service by design. Preserving that trust requires a healthy tension of shared responsibility between the security teams demanding it and the cloud providers offering it. A new paradigm shift requires a deeper acknowledgement that an emphasis of the security problem “up the stack” to the application layer is needed.

    For security teams, ensuring the protection is built in from the beginning and moves dynamically in lockstep with the workloads requires a much closer partnership with application developers and DevOps teams. This ultimately leads to a richer understanding of the business applications by security teams, creating a more cooperative business-aware and security-minded culture. Getting there will help reduce the tension and improve the overall delivery of secure cloud services regardless of where you sit in the cloud provider/consumer ecosystem and ultimately enables value creation to the business. To get there, a strong partnership must be fostered.

    There are obstacles to moving up the stack. In most companies, the reality is that many security teams are not well-aligned to keep up with this change while the business continues to make cloud-based investments, making the problem worse. Security’s comfort zone seems very much still focused on perimeter defense, but this emphasis isn’t optimally aligned to a cloud-first future. Even when forward-leaning security shops realize a need to change, they often get pushback from app developer teams because security reviews can delay deployment and security tools create “noise” and false positives for app developers. Also, traditional security tools often do not work well in cloud environments.

    Interestingly enough, the No. 1 concern of app developers is preventing data breaches and cyberattacks, a survey of 500 developers and development managers by Veracode found. Less than one-quarter of developers said meeting customer or regulatory compliance is their top concern, while 21 percent said meeting budget and delivery schedules is their top concern, and 19.4 percent said delivering secure code to pass internal audits is a priority. Furthermore, app developers who work with security teams get “major and tangible business and technical benefit,” according to a survey of 150 security and app development pros conducted by Forrester Consulting. Almost all of the collaborators said that working together leads to major or moderate benefit in customer satisfaction.

    Respondents said the more frequently they collaborate, the better the results, “including improved customer satisfaction, business/IT alignment, quality and frequency of releases, and the rate of innovation at their firms.”

    By overcoming barriers to collaboration, app developers and security teams can leverage this knowledge to improve their approach and also come to the table with solutions aligned at moving up the stack. First, they can perform code analysis to uncover vulnerabilities early in the app development process. Second, they can work on stronger runtime protection once the SaaS application is deployed. Code analysis can be used to make runtime protection better, and runtime data can be used to improve code analysis. This creates a continuous improvement loop between the two and both teams can work on code analysis and runtime protection together.

    To achieve this continuous improvement loop, companies must work to break down traditional work silos that exist because of a mismatch in expectations. App developers, measured for speed, need to receive security information accurately, early and with sufficient context to correct problems during software development. Security pros can benefit by installing security tools in production that understand the security needs of their applications, as opposed to tools that require security pros to write rules, tune the tool and then deal with large number of alerts.

    The goal is to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process rather than after deployment, when liability, revenue and reputational risks are the greatest. It is also important to realize that achieving zero defects in source code is a noble but difficult-to-achieve goal. Instead of focusing on extremes, the goal should be to establish a continuous improvement logic in CI/CD (continuous integration/continuous deployment), where bugs are identified, some are fixed and the remainder have fast and accurate runtime protection.

    This shift in thinking and processes will give companies fewer security worries and enable them to more proactively embrace a SaaS-first mentality with higher confidence and trust levels. Companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and improved levels of software security.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.