The 2019 State of the Union Address, delivered Feb. 5, was light on anything tech-related. But just a week later, Feb. 11, technology was the focus of an executive order that launched The American Artificial Intelligence (AI) Initiative. Why do we need a national AI initiative, and what does it have to do with DevOps? (Hint: You may need hardware and a hybrid cloud strategy for your AI initiative.)
Investments in AI technology are exploding worldwide. Most analysts believe that while the total number of startups and equity deals to date still favors the United States, China is spawning startups rapidly, thanks to their recent AI initiative. According to just-released data from CB Insights:
“While China accounted for only 10% of global AI deals in 2017, Chinese AI startups took 48% of all AI funding dollars that year, surpassing the US in AI funding for the first time.”
The long tail doesn’t lie. A big global competition here is a good thing, though, and the scoreboard has spurred movement. The American AI Initiative lays out five principles, paraphrased in brief:
We need to drive technological breakthroughs in AI.
We need technical standards for development and testing.
We need workforce training in skills and applications.
We need to be able to trust AI solutions for privacy.
We need both open markets and protection for “critical” technologies.
Go, Team America! What, you expected more than motherhood and apple pie out of the White House? I’m not going there. I don’t think any administration could prepare the level of technical insight needed for something of this magnitude. It can, however, lay a course and task agencies for technology plans and funding proposals—and about two-thirds of this executive order is devoted to timelines for those.
Let’s assume this AI initiative comes together with real dollars, and everyone including your competition is at work on AI. You may be thinking, “This is easy. I’m looking at a prominent cloud vendor’s machine learning webpage right now and it says, ‘No machine learning skills required.’ Its solution is based on its libraries of algorithms plus cloud-based workload acceleration hardware.”
If that approach solves your specific problem, that’s great. Many use cases will fit those offerings. However, I’m thinking that a lot of you out there won’t turn over your data and your privacy control to a single vendor. Based on what I’ve seen, while the public cloud may be fast enough for some use cases, it’s woefully non-deterministic for others. You may be able to afford all kinds of time and elastic cloud resources for training, where time may be measured in weeks or months on bigger machine learning data sets.
Real-time inference is a different game. There. Will. Be. Slowness. One missed result can be very costly—ask any autonomous vehicle developer, then look at all the hardware sitting in the trunk. Public cloud solutions are woefully non-deterministic, especially as everyone and their dog starts using them. The CEO of another big cloud vendor just said in an event keynote that most AI solutions will split 40/60 private/public cloud. She went on to say if you’re regulated, it’ll be more like 60/40.
Most current startup investment is headed for AI chips. Machine learning is the ultimate workload optimization problem. By adding compute nodes with clusters of GPUs, FPGAs or dedicated system-on-chip (SoC) designs, inference speed-up is achievable. Whatever approach you chose, you’re probably going to want workload optimization safely in your private cloud instance within a hybrid cloud AI solution.
You’re also going to want control over differentiation of your solution. Open source AI software solutions are great because they handle a fundamental base of value. However, AI-enabled applications are very likely to run into problems at scale. Open source will get you to prototyping quickly. Your innovation will be tested as real-world, real-time issues develop. If you can get a truly differentiated hybrid cloud AI solution that proves to be fast, reliable and secure, you’ll have a huge competitive advantage.
Again, this looks like a perfect job for a DevOps team. Here’s where to start on your AI initiative, in increasing order of difficulty:
Have someone get familiar with machine learning and AI public cloud solution offerings—those vendors are easily found.
Also get familiar with open source frameworks such as TensorFlow, Caffe, Cognitive Toolkit, PyTorch, MXnet, DeepLearning4J and others.
Look at your preferred distributed computing framework for recent innovations in AI workload optimization; for instance, a lot of work is happening around Hadoop and Spark.
Inventory the problems you think AI might solve in your organization and see how they line up with those potential solutions.
Experiment and discover where the bottleneck in your preferred algorithms might be; those will be candidates for a hybrid cloud workflow optimized solution.
If there’s a profound bottleneck, you’ll need to evaluate the best hardware solution, meaning someone on your team (or a consultant) should understand GPU code or FPGA design.
For the most severe AI challenges, more companies will be considering either off-the-shelf AI chips or custom SoC designs—even companies that have never designed chips.
My point here wasn’t to provide a primer on AI technology; that’s a huge topic. The American AI Initiative is a call that teams need to move on AI now or risk being left behind in the competitive prop wash. You also shouldn’t wait for someone to generate the exact solution you need out in the marketplace. With the feds driving a sea change in AI, investments and technology will be shifting even more rapidly, and it’s best to get in front of it.
If you’ve started already, how’s your AI initiative going? Are there other areas in AI or machine learning you’re curious about that would be a good topic for future posts? Reach out if you’d like to discuss this.
Normalization of infrastructure through open source technologies is one way to make the move to the cloud an easier process for organizations.
For many modern companies, growth often means growing through acquisition. As organizations become larger, it often makes sense to acquire existing companies who are already creating the solutions they need than try to build them from scratch. However, this can often create a variety of conflicts and challenges—one of which is around infrastructure. For other companies that have grown more organically, it often can be difficult to modernize their legacy systems and bring their technology stack into the 21st century.
But cloud comes with big benefits: Some studies estimate a cloud-based infrastructure can reduce IT overhead costs by as much as 40 percent while also giving IT leaders a flexible way to scale up and down as needed. It also lends itself well for automation tasks, helping free valuable development time to add meaningful value to applications. And, the cloud isn’t just for tech startups. For example, a recent McKinsey & Company study noted that financial services companies have the highest percentage of server images deployed in private or public clouds, approaching nearly 100 percent (versus a median adoption rate of 19 percent). Cloud is certainly a hot topic, and for good reason.
In an ideal world, the IT landscape would be a greenfield, where every organization could start with a blank slate and build out their optimum infrastructure. But for most businesses, it is often more of a brownfield—muddied with old systems and stodgy practices—and it’s not always clear the best way to build on top of it. As more and more organizations look to a hybrid cloud approach as the infrastructure mode of the future, the need for a way to migrate legacy systems more easily is becoming an increasing necessity.
One of the ways to approach this is through the concept of normalization. This is a focus on utilizing industry-leading open source stack technologies that can create a hybrid cloud solution that is consistent and just works immediately: Kubernetes for containers, Fission for serverless functions and OpenStack for VMs, for example. As anyone in IT knows, this goal of normalization is nothing new, but achieving it can go a long way in helping your organization move into the cloud.
The reason behind this focus on providing a solution that leverages open source technology is the goal of creating this normalized structure that works across different cloud providers. This approach is because all the big three cloud providers have their own special services: Google has TPUs, Amazon has Lambda and Azure has Dynamics CRM. As you move data centers into the public cloud, you still have islands of infrastructure that are all built and run differently. How can DevOps truly have a consistent way of building and operating software in this sort of atmosphere? Open source technologies are a very powerful way to normalize that because they provide a solution that plugs into any infrastructure that you want.
One of the other keys to help bring your legacy systems into the cloud is to embrace change as it comes. While this is obviously a less technical recommendation than the above, it is still an important component to achieving success. It is no surprise that this sort of approach is one of the main tenets of the DevOps community that dates back to the beginning of the philosophy. It really started with the Puppets and Chefs of the world in the late 2000s and then continued with the rise of the OpenStack community. Finally, containers really started to form, from Vagrant and now to Kubernetes. Along this route, the IT industry has become much more sophisticated and there are a greater number of opportunities to achieve the normalization necessary to ease the transition to cloud—but only if you’re flexible and willing to adapt to change.
A related important distinction is to understand that complexity exists, and it’s not feasible to eliminate that complexity. Rather, you can take an approach of subdividing it and trying to contain and limit complexity. The strategy of normalization allows you to do this and keep complex parts of your infrastructure isolated as much as possible.
While there are many approaches to moving legacy systems into the cloud—from rehosting (a lift-and-shift approach) to refactoring (completely re-imagining how the application is architected and developed)—turning your current infrastructure into a cloud by leveraging existing and powerful open source tools is one of the most effective approaches that extract the most value for many organizations. This hybrid cloud approach gives organizations the ability to not only leverage cutting-edge cloud solutions that are agnostic to provider, but also provides a real way for companies to continue utilizing legacy systems that still provide meaningful value for their applications. This flexible, bespoke approach to hybrid cloud enables an entirely new approach to software infrastructure and opens many new doors for sustained success.
Here’s a full discussion on this topic with Alan Shimel, editor in chief of devopsy.kinsta.cloud, posted on DevOpsTV:
Moving to the cloud is becoming a must for many companies if they want to grow beyond their current footprint and be more innovative. But for many companies—especially those in the SMB space—their transition to the cloud is hindered by a lack of knowledge and experience, which often results in difficult migrations that sometimes just aren’t successful.
Since its inception, nClouds has helped organizations of all sizes move to the cloud successfully. Its experience as an AWS Premier consulting partner and its well-architected approach to cloud migration helps companies get the most from their infrastructure by engaging with the cloud, whether they’re adopting a hybrid environment or going all in on cloud.
In this DevOps Chat, JT Giri, nClouds founder and CEO, and I speak about the triggers that push companies to adopt cloud, some issues companies face in their decision-making and infrastructure’s role in an increasingly cloud-based IT world.
As usual, the video is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat, or in this case, perhaps, watching a DevOps video. Happy to be joined here by my friend J.T. Giri, who is the CEO and founder of nClouds. J.T., welcome.
J.T. Giri: Hey—good morning, Alan. Thanks for having me.
Shimel: My pleasure, nice to have you here. J.T., let’s first of all say Merry Christmas, happy new year.
Giri: Thank you, and you.
Shimel: Yeah, it’s been an exciting—we were talking off camera, off mic—it’s been an exciting quarter for you. You’re a new time dad and moving homes and at the same time, nClouds’ business seems to be just booming along with everything else associated with Amazon Web Services and the cloud. So, congratulations.
Giri: Thank you. Exciting times.
Shimel: Yeah, it is. So, J.T., I wanted to talk a little bit about—you know, there’s people listening to this or watching this who are saying, “You know, I wanna be like Google,” or, “I wanna be Facebook” or, “I wanna be one of these unicorns in that I wanna harness the cloud. You know, we have our servers in a closet here or a data center or a third-party data center, but we’re not really cloud. And everything seems to be in the cloud. We wanna move to the cloud, but you know, we’re only maybe 250, 500 employees. How do we do that, right? Do we need a helper, like an nClouds. Do we need to update everything? Do we throw out the baby with the bath water and start new?”
I want you to tell us a little bit, sort of, what’s the typical sort of customer journeys that you see when you guys engage?
Giri: Yeah, absolutely. So, Alan, you know, we’ve talked in the past. I’ve been migrating companies to AWS ever since EC2 was in beta. And, as I would migrate these companies, people would realize that they need someone to manage it, right? So, that’s how, sort of, nClouds came to be. And as you mentioned, this has been an incredible year for us. We doubled the size and revenue and the number of people.
What we were seeing in an SMB type of market, when companies migrate or when they try to migrate to AWS, they still need to follow—obviously, they need to follow best practices because cloud or AWS is constantly changing, and the skill set is just not there. So, that’s where we come in play. We can make sure that your infrastructure is well-architected. We take an approach of migrating in a way where you’re really taking advantage of the cloud—so, for example, using containers, things that are really gonna help you to harness the power of cloud. And then, for most of our customers, you know, we’re providing 24/7 support. And when we see people try to do this themselves, they get a bad taste of cloud. They’re like, “Oh, this is not for us. We’re not really innovating fast.”
So, that’s why, Alan, we’ve been very successful, because there is a huge gap in SMB type of companies. There is a skill gap and just experience. We bring that to the table, and it’s been incredible. We’re able to add a lot of value.
Shimel: Sure. So, J.T., early on there, you said something about when an organization needs someone to help them manage their cloud migration—when does an organization recognize that they need someone to help them? What’s sort of a trigger point? You know, as, again, we spoke off camera a little bit—is it when someone dives in the pool and says, “Oh, my God, I can’t swim, it’s too deep?” Or is it, before you dive in the pool, a prudent person hires a swim coach, you know what I mean?
What are sort of the trigger things that people should see as a red flag or as a trigger event that says, “Hey, man, I should be getting some help, here”?
Giri: Yeah, that’s a great question. So, basically, it depends when the companies come to that realization that we need some outside help, right? Sometimes, it is that they will try to do the project themselves, or in other cases, they realize that they really want to just focus on delivering value to their customer, right? They really wanna just innovate fast.
So—and they see how they can just stay focused on that, and that’s something we do incredibly well. We have a build—we build systems and processes together where our key focus is to make sure the customer can deliver value to their customers fast and we want to make sure the infrastructure is not getting in their way.
So, you know, it’s just, this is becoming more and more popular, like, DevOps as a service, where companies are reaching out to partners like nClouds to help them with DevOps related tasks, like, with the migration, setting up CI/CD pipeline, becoming an extension to their team, so they can focus on their core business, right? And, you know, it really depends when they—sometimes, they come to that realization pretty fast, or sometimes they try to do things themselves, and when things don’t work out, they try to use someone like nClouds.
Shimel: So, J.T., generally, one of the hardest things in life is learning when to ask for help.
Giri: Right.
Shimel: And that includes cloud migrations and everything else. At the SMB level, mid-enterprise level, you don’t have an elaborate or as big a structure as, let’s say, you do with a large enterprise where you have layers and layers of management and hierarchy—a lot of the organizations you deal with are rather flat in their management structure.
So, who is it in the organization who finally kinda raises his hand and says, “Wait a second, I think we should engage in some professional help, right? I think we should being in some experts to help us.” Is it the CEO, CIO, someone lower than that? What’s your experience?
Shimel: Yes, normally, CTO, VP of Engineering type of person. And also, you know, as you know, we became a premier partner with AWS last year. So, AWS is—Amazon, it’s no secret that they’re very customer obsessed. So, they will—Amazon, when they’re speaking to a customer and if they see the customer is struggling, they will introduce someone like nClouds to help them out with the migration or just modernize their infrastructure. And sometimes, you know—actually, many times, they can come in with funding where they will offset some of the costs.
So, for a customer, it’s just like a no-brainer to see if we can have some external experts come in and fix up the infrastructure or streamline the infrastructure. So, you know, the conversation, normally, we do get a lot of business directly from people reaching out, like, “Hey, we need DevOps help,” but we also get a lot of business directly from AWS where they identify this customer needs help, and we get involved that way.
Shimel: So, I’m just gonna bring up two questions. The first one is on track with what we’re talking about. So, now the CTO or CIO or an executive says, “Yeah, we’re gonna bring in nClouds,” whether AWS referred it or is partially subsidizing it or what have you, but, “We’re gonna bring in nClouds or some other type of help”—is there any sort of pushback or resistance normally with, you know, when you’re dealing with people? The—not first responders, but the individual contributors who feel like, “Hey, man, I don’t wanna be replaced. I don’t wanna be outsourced. I don’t want to give up my cheese to some outside company who’s helping us” or, if so, how do you overcome that? How do you work with an organization like that?
Giri: Yeah, so, normally, there’s not a pushback, Alan. So, I was actually re-reading “The Venus Project” yesterday, and I was just reading the story of Brent, right?
Shimel: Mm-hmm.
Giri: So, when you’re talking to these customers, some of these guys are on their honeymoon with their pager with them, right? And then, when you’re coming in and you’re saying, “Hey, we’re gonna help you out with 24/7 support so you can get your life back” or, you know, “We’re gonna help you to streamline this DevOps work which you never really got the opportunity or time to work on, we’re gonna help you out with that,” right? And it’s incredible.
Sometimes, maybe the initial impression might be the same as you describe, like, “Hey, are you gonna take my job?” But as they understand the value, they normally are super happy. And another thing we do, Alan, in most of our engagements, we do this assessment called architected assessment where we’re coming in and we’re just reviewing your infrastructure to see how well you’re architected, and after that assessment, we give you, like, a roadmap, like, what are some things you should focus on the first month, and what are some things you should focus on short term and long term? And the assessment goes over cost, security, reliability, performance, and operation excellence.
So, you know, we can get, in the short-term road map, we can show some quick wins where the customer sees the value and they also get confident in our ability, so that’s sort of the path that works really well for us right now.
Shimel: Got it. J.T., another thing you mentioned is that nClouds is a premier Amazon partner. And, you know, in today’s world, we throw out platinum and gold and these sort of levels all the time—but really, within the Amazon hierarchy, a premier partner has sort of, they don’t hand that out like candy. Talk to us a little bit about what’s entailed in being an Amazon premier partner.
Giri: Yes. It’s a top tier status with AWS and in order to get there, like you said, there is only 25 premier partners in North America, and you have to show case studies, you have to show the training path of your employees, and you also have to have multiple competencies, like, we have DevOps competency, we have migration competency, and we’re also the well-architected partner.
And it’s just very subjective. You know, if you work closely with Amazon, even if you hit all the check boxes, they want to make sure that quality is there for premier partners. So, they look how you work well with your customer, what does your customer experience looks like, because that’s what Amazon cares about that as well.
So, you know, it’s just very hard to get to this status, and we’re honored to be at this level right now. This is great.
Shimel: Yep. So, J.T., let me go next kind of where I want to take this, and that’s—you know, two or three years ago, migrating a company onto an AWS, or it doesn’t have to be AWS, migrating a company onto the cloud, you know, you set up some virtual instances, maybe they had some separate storage, stuff like that, EC2 kinda stuff. But, you know, I just got back from Seattle a couple weeks ago from KubeCon and CloudNativeCon—Reinvent was the week before that. And certainly, Kubernetes and containers are kind of really quickly, quickly, quickly changing the landscape, here.
You know, are you seeing that as well? And what does that mean for—typically, SMB businesses are not leading edge or bleeding edge, right in [Cross talk] option?
Giri: Yeah.
Shimel: What are you guys seeing?
Giri: Yeah. You know, it’s very interesting. Who would’ve thought that the infrastructure we built a couple years ago would be considered a legacy infrastructure, you know? People using EC2 instances and an auto scaling group in Amazon’s world will kinda be called outdated right now.
So, we’re seeing incredible push and a lot of sort of initiatives on our customer side where they wanna go containers, pretty much like 90 percent of our engagements are around containers. Because it’s a no brainer, right? It makes the CI/CD pipeline much easier. You know, most of the time, containers are automatically integrated with scaling, so you can really binpack your resources, it has impact on your cost. So, you know, this is just—it just makes the infrastructure far more streamlined and far more easier to manage.
And as I mentioned, Alan, I’ve been migrating companies to Amazon and EC2 from the last 10 years, and I’ve been managing infrastructure as long as I’ve been migrating. So, it’s just, when I’m building infrastructure right now, it’s a no-brainer to build something using Kubernetes or on AWS we use EKS or—you know, depending on what the customer wants to do, and we had a customer the other day where they were saying, “I just wanna focus on delivering product to our customers, so what is the easiest way?” We use Fargate for them. Depending on the customer requirement, we’ll go Kubernetes, but long story short, it just makes a lot of sense these days to build infrastructure on containers, because they really streamline how you manage it in the long run. It just makes life easier.
Shimel: And that’s even at the SMB level?
Giri: Oh, absolutely, yeah. I mean, because the needs are the same. You need CI/CD pipeline, you need a way for you to scale infrastructure, you need a way for you to run batch or cron job type of jobs. And when you go with something like containers, you get there—like, you know, you don’t have to build home grown tools to facilitate these things. You know, containers or EKS or Kubernetes, they allow versioning when you’re deployed or auto scaling is sort of built in, you know, you can schedule batch jobs.
Just, it’s a no-brainer, you know? If you’re building out infrastructure, you should definitely explore containers each time, and that’s what we try to do every time. And it’s just incredible, the amount of success we’ve had before and after.
Shimel: Sure. So, as we sit here at the dawn of a new year, if I would’ve asked you in early 2018, do you think Kubernetes and containers would be one of the major stories of the year, I don’t know if you would’ve said yes or no. But as we sit here in the dawn of 2019 and we project ahead—let’s say I interview you and everything’s all well and at the end of next year, the end of this coming year, 2019, we sit down and talk about, “Well, what’s 2019 really show?”—what do you think are the big stories this year, J.T.? What do you think, coming down the pike, especially—I’m not talking about the world view. For nClouds and for your customer base, what do you think is really big for you in the coming year?
Giri: Yeah, so, I think in general, the application modernization will continue. We continue to see that trend, and this is also going to be big in SMB. So, we will continue to double down on AWS. It’s been an amazing partner. Our core values, our partnership is based on shared goals, so we’ll continue to kinda double down on that relationship.
And we’ll continue to utilize this well-architected framework. It helps us to assess the customers when we’re onboarding and it helps us to manage the customer, like, every time the customers were managing, we continued to run a well-architected assessment to make sure they’re well-architected, and they continue to stay well-architected.
And, yeah, I mean, just continue to focus on SMB, AWS, continue to align with well-architected framework. We also just spun off another company, it’s called nOps, and basically, it just helps to make sure the customers are well aligned with well architected framework, and it’s available on AWS Marketplace. So, we’ll continue to invest in that, because that solution has been incredible, nOps. A lot of our customers are seeing value in that, so, we are actually working with Amazon to give that solution to other partners like nClouds who can use it to manage their infrastructure to make sure the infrastructure is well architected, and we are also offering it to end customers who can use that tool to assess their infrastructure and continuously stay in compliance with well-architected framework.
Shimel: Excellent. You know, nOps, that’s something we’ll have to discuss on our next chat, J.T.
Giri: Yeah, absolutely.
Shimel: Well, you know what? We’ve been on almost a half hour here, so, unfortunately we’re about out of time for this one. J.T. Giri, CEO and founder of nClouds, thanks for being our guest on DevOps Chat.
Giri: Thank you so much for having me.
Shimel: My pleasure. Best of luck to nClouds this year, best of luck to you personally with your family and everything else, you know, it’s gonna be a busy year for you, my friend.
Giri: Absolutely. Thank you. Thank you.
Shimel: Alright. Hey, J.T. Giri, nClouds—you’re here with Alan Shimel on DevOps Chat. You’ve just listened to another chat. Bye bye, everyone.
IDG and Insight Datalink recently conducted a survey into how companies were doing on their digital transformation journey. Like so much in technology these days, it is easy to feel as though you’ll be left behind if you aren’t well on your way with digital transformation.
You’re not.
Who Are You People, Anyway?
The survey had decent industry distribution and was focused on director level and above in larger organizations, with more than a third of respondents in financial services or high tech. So in short, a third of respondents are the very organizations most motivated to implement a digital transformation project.
Nearly Half of Respondents Haven’t Even Started
Let’s get the easy one out of the way first: The survey showed that a significant proportion of companies had done nothing more than talk about digital transformation.
Adding up “It’s on our radar” and “We’re talking about it,” we get to 44 percent of respondents who haven’t even started. In fact, due to the nature of digital transformation, I would argue that less than 1 in 4 are actually doing it. Then there is the 24 percent who are undertaking enterprise-wide transformation: You can convert projects, but that isn’t transforming the way you do business. It is a start, so I admit this is well and truly a debatable statement, but true transformation is cross-app, cross-team, agile and locale-mobile.
Why So Small?
Since we frequently hear about digital transformation and how important it is, “Why are the numbers so low?” is a valid question. The truth is that transformation of complex infrastructures is difficult. There just isn’t any way to get around that fact. When there is a mainframe with heaps of data and a midtier that often has replication of mainframe functionality on it, then separate apps that are doing web-based transactions in (insert language here, but normally Java in the above environment), there are many parts that are complex, and something as simple as moving and/or rationalizing data stores can be majorly complex.
But I won’t go on and on here, I’ll simply show you what IDG found.
Looking at mainframe toolsets in particular, there have been massive steps forward over the last several years to make them more compatible with modern development and deployment practices. But making use of those changes often requires updating systems that are not otherwise broken. And there is always the risk that such updates will break something. The more research an organization does into modernization tools, the more comfortable they are that there is a valid path—but that doesn’t make it easy when it is added work.
Data privacy also ranks high, and that is because IT has been dealing with locking down data in a data center for ages. Additionally, some spectacular configuration mistakes in public cloud datastores have made us all gun-shy. There are solutions to data security in public cloud from a variety of companies, but that doesn’t change that we’ve all followed “due to bucket misconfiguration” stories while cringing.
Technology silos are a fact of IT. There can be some breaking down of those silos, but they are unlikely to disappear completely. The EMC specialist or Cisco specialist are unlikely candidates for elimination in the quest for reduced silos. (I just picked two roles whose knowledge sometimes astounds me—both for the depth these people can have, and for the requirement that they need that depth.) Working your network and storage teams into the digital transformation without undermining the thing that makes them valuable—their silo-specific knowledge and insight—is a challenge that can be achieved, but not by “breaking silos”; more like, “increasing communications between silos while reducing silo behavior.”
If You Dive Like That, You’ll Stall!
The last point in this survey that I’d like to address is the “Stalled Digital Transformation Initiatives” slide. (There is a ton of good data in this survey, but these three fit together really well, so I pulled them out.) The fact is that if you are attempting to transform a complex system, you will have wins and losses. Some things will work out better than you planned, while others will not work out as you had hoped at all. I believe that, due to the question’s wording, that is what we are seeing here:
Yes, 51 percent would be appalling in any other context, but the question was, “Have any of these difficulties prompted you to stall or abandon any IT transformation initiatives?”
Any is a big word. In fact, any is the largest word in that question. If it were worded with “your” instead of “any,” I will guess the positive answers would be a limit approaching zero.
If you pronounce a large reorganization and implementation of a slew of new processes, statements such as “that doesn’t fit our infrastructure” are going to shake out. That doesn’t spell doom and gloom for digital transformation; it is simply another obstacle to overcome. Dropping it for now, while focusing on the more viable portions of the plan is common sense, unless whatever isn’t working is core to the transformation. Then it still causes you to stall while figuring it out.
Honorable Mention
On average, respondents said they expected more than one-third of their digital transformation activities to be conducted by third parties. That’s a big chunk. Not “off-shoring” big, but still a large portion of work they expect to outsource to get the job done.
So. Much. Typing.
Okay, I’m about to shut up now. The takeaway is pretty straightforward. Contrary to hype, you’re not behind on your digital transformation. It’s a tough job, and knowing what you hope to get out of it before starting will help you to continue when things get rough. And they will get rough. The word “transformation” should tell you that. But keep going: There is better/faster/smarter/more mobile out there if you can stay on track, and because they are complex systems getting complex modifications, slow and steady does indeed win the race.
And just remember, you’re responsible for those horribly complex, hard-to-transform systems doing what they do. Every day. Making them better and easier to manage is a no-brainer, but so is taking a moment to bask in the idea that you’re keeping things running in an environment that is complex.
On the heels of IBM announcing its intent to acquire Red Hat, VMware announced at the VMworld Europe 2018 conference this week an extension of its longstanding cloud alliance with IBM.
Red Hat competes directly with VMware; yet, there are also more than 1,600 customers running VMware on the IBM cloud. Ajay Patel, senior vice president of product development for cloud services, said VMware remains committed to the IBM cloud alliance even while its relationship with Amazon Web Services (AWS) continues to expand.
VMware and IBM jointly announced this week they have opened Joint Innovation Lab and that IBM Cloud Private Hosted can now be installed on VMware vCenter Server on IBM Cloud. In addition, IBM Cloud for VMware Solutions are now integrated with the IBM Cloud Kubernetes Service. IBM is also adding support for VMware NSX-T Data Center to provide VMware customers with access to a network virtualization (NV) overlay on IBM Cloud.
In addition, VMware vRealize Operations automation software is now available on IBM Power Systems, and VMware will use the IBM Watson cognitive computing platform within VMware customer support portals.
Despite the obvious tension between VMware and Red Hat and IBM and AWS, Patel noted that VMware has more customers running on the IBM cloud service than any other cloud environment. In addition, IBM, VMware and Red Hat all are committed to advancing Kubernetes. Point of fact: VMware, separately at the conference, announced its plans to acquire Heptio, a provider of management tools for Kubernetes and added support for Kubernetes running on top of VMware virtual machines in version 3.5 of VMware Cloud Foundation.
VMware, via its alliance with IBM, is making a case for enabling customers to run stateless components of an application on Kubernetes, while maintaining stateful components such as databases on virtual machines, which provide better support for persistent storage.
IBM said it intends to treat Red Hat as an independent subsidiary capable of making independent alliances, in much the same way VMware operates as an independent unit of Dell Technologies. It may take a while for IT organizations to get used to navigating strange-bedfellow relationships in the era of the cloud; for example, Red Hat has an extensive relationship with Microsoft that spans both Microsoft Azure and on-premises IT environments.
What remains to be seen is the degree to which DevOps teams will navigate conflicting vendor alliances in isolation from one another instead of trying to unify the management of all those clouds under a common framework. A recent IDC report finds that while most customers (64 percent) are employing multiple clouds, the degree to which those clouds are interoperate varies widely. IDC finds that only 24 percent of IT organizations have a high degree of interoperability between their cloud environments. Another 40 percent say they have achieved low interoperability between their clouds. Only 7 percent say they have a true hybrid cloud in place.
As the number of organizations with hybrid cloud capabilities starts to increase, the next battle in the cloud won’t be focused on what platforms are employed as much as what management plane might be employed to unify them all.
As Hybrid Cloud and Serverless Continue to Gain Ground, Organizations Rush to Keep Up; Fewer than Half Have Dedicated Cloud Security Teams
Tel Aviv – November 6, 2018 – Alcide, provider of the most comprehensive full-stack cloud-native security platform, today released the findings of a new industry report: 2018 Report: The State of Securing Cloud Workload based on responses from close to 350 security, DevOps and IT leaders. The report reveals that as more organizations embrace hybrid cloud – with more than 50 percent claiming a hybrid cloud setup – and serverless, now used by close to third of organizations, they lack the tools and specialization to keep up. 75 percent of respondents expect to see an increase in the number of security tools they rely on in the next year, while over half share they still manually configure security policies. The resulting complexity has the potential to slow critical business functions in the absence of an integrated security approach to distributed cloud environments.
The pace of innovation on cloud-native environments places significant burden on traditional security practices. Not only is there a need to support new technology options – quickly moving from traditional virtual machines to containers, serverless, and newer constructs such as service mesh – but there is also a difference in how security and DevOps teams consider their needs and workflows.
Alcide’s report, conducted in August 2018 in conjunction with Informa Engage, reinforces the idea that new practices and technologies are disrupting traditional security practices, with findings including:
Cloud complexity increasing, with hybrid cloud as the new infrastructure normal:
While virtual machines (VMs) remain the most common cloud computing environment (83%), containers (37%), serverless (28%), and service mesh (21%) are gaining traction.
Hybrid and multi-cloud approaches now make up more than three-quarters of all configurations (77%).
Serverless running in production; most bullish about its security
Despite some security concerns, the majority (57%) of serverless users are currently running it in both production and development.
The majority currently using serverless have a high degree of confidence in its security, while one third (32%) express a lack of confidence in the security of their environments.
As cloud infrastructure complexity grows, security becomes a shared responsibility with DevOps
Fewer than half of organizations (45%) now have a dedicated security team responsible for the cloud, with 35% of all organizations now using either a DevOps team or dedicated DevSecOps team for security.
Hybrid cloud complexity pushes Dev, Sec and Ops teams to look for more tools to secure their distributed environments
Over two-thirds (75%) expect to increase the number of tools in use over the next twelve months – with no one expecting to retire any tools in use
One-third of organizations reporting using more than five tools for cloud security
Proliferation of cloud security tools leave the enterprise vulnerable, point to need for intelligent policy automation
More than half (60%) of organizations rely on manual configurations of security policies for their apps, while almost all organizations (90%) rely on multiple individuals to configure and set policy rules.
“Our report validates what we’ve seen with our own customers – modern organizations are striving for a consolidated security approach that will support business velocity and tackle the challenges associated with the overhead of multiple tools in use,” said Karine Regev, VP Marketing of Alcide. “Modern teams can’t assume that emerging technologies like serverless are secure, and need a practical and uniform enforcement and management of security policies to control disparate and cloud-native services, infrastructure and environments.”
Access the full report here for additional insight.
About Alcide:
Alcide’s Cloud Native Security Platform protects any combination of container, serverless, VM and bare metal. Offering real-time, aerial visibility, threat protection and security policies enforcement, Alcide secures the cloud infrastructure, workloads and service mesh against cyber-attacks, including malicious internal activity, lateral movement and data exfiltration. For more information, please visit www.alcide.io
IBM’s proposed acquisition of Red Hat for $34 billion will have an immediate impact in raising awareness for a programmatic approach to managing hybrid clouds based on best DevOps practices.
A recent survey published by International Data Corp. (IDC) finds most organizations (64 percent) have already embraced multiple clouds to varying degrees. Only 7 percent of respondents said they have built a truly hybrid cloud. Another 24 percent, however, said they have achieved a high degree of interoperability across multiple clouds. IBM made it clear this week that its primary motivation for acquiring Red Hat was to tap into a trillion-dollar opportunity that will manifest itself as hybrid cloud computing continues to evolve. In fact, IBM is betting that Kubernetes clusters will play a key role in advancing the state of hybrid cloud computing.
But for hybrid cloud computing to take hold, it’s also clear the level of mastery over DevOps within enterprise IT organizations will need to improve substantially. In fact, hybrid cloud computing might not even be the ultimate destination, said CloudBees CEO Sacha Labourey. Enterprise IT is increasingly being defined by programmatic services rather than platforms, he noted, and those services need to be weaved together to drive modern applications. But where each of those services resides is becoming less relevant as organizations become more DevOps proficient, Labourey said, noting the rise of hybrid cloud computing will drive more organizations to embrace DevOps to bring order to the services being consumed.
“Within a hybrid cloud DevOps will be required,” said Labourey.
While platforms are still relevant, they increasingly are being hidden behind services that expose an application programming interface (API), added Chip Childers, CTO of the Cloud Foundry Foundation, which oversees the development of the open source Cloud Foundry platform-as-a-service (PaaS) environment. A developer consuming a service might have little to no idea what platform that service runs on.
“IT teams are building on the abstractions that have gone before,” Childers said.
The ability of one organization to differentiate itself will come down to the maturity of the DevOps processes they rely on to most efficient consume a service, he added.
Demand for that level of DevOps expertise is already starting to accelerate, said Tim Beerman, CTO of Ensono, a provider of managed IT services. As IT continues to transform into microservices enabled by containers and serverless computing frameworks, the complexity of the overall IT environment requires a more sophisticated approach to managing the overall environment, he said.
But, he added, “A lot of organizations simply don’t have the talent.”
Of course, IBM is betting that once it owns Red Hat, more organizations will look to IBM Services for that expertise. But as always, competition across the IT services space remains fierce. IBM is also betting that it will provide the management plane through which hybrid cloud services will be unified. But even there, competition from rivals small and large will be significant. Vendors such as Rackware are already providing frameworks for managing hybrid clouds.
While hybrid cloud computing is still relatively immature, organizations that embrace DevOps will be much further down that path than others, said Todd Matters, chief architect at Rackware.
“DevOps will absolutely be a critical part of hybrid clouds,” he said.
IT has always been about striking a balance between people, process and products. It’s too early to say whether IBM will recoup its $34 billion investment to acquire Red Hat. But the deal inevitably will lead to a greater awareness for a more comprehensive approach to DevOps capable of spanning a hybrid cloud computing environment that includes multiple platforms.
The modern data center is constantly evolving to keep up with the demands of always-on, anywhere computing. Long gone are the days of monolithic, on-premises data centers. Today, the computing modus operandi is that of the hybrid cloud, which, according to Statista, will be worth close to $50 billion in 2018—just about double what it was in 2014—and will grow to almost $92 billion by 2021.
As more and more DevOps and security teams are integrating hybrid cloud environments and serverless architectures, they need to gain visibility and insight into the increasingly distributed workloads provisioning and supporting their applications. Without a single pane of glass across their hybrid clouds, Dev, Sec and Ops teams cannot quickly discover vulnerabilities or identify and respond to attacks.
The emerging best practice to the cross-cloud visibility conundrum is unified stack observability. Unified observability is the ability for Dev, Sec and Ops to share the same application-aware monitoring environment for vulnerabilities, threats or attacks across all workloads supporting their applications. The idea behind unified observability is that each team can look at the different stack layers as one—with an app-aware, single-pane, top-down view. For Dev teams, unified observability means that they can see and define all the third-party services connected to their applications; for Ops, it means they can see and monitor all workloads. And for Sec teams, it means the ability to set security policies for detecting and blocking attacks at each layer of the app stack by enforcing policies uniformly. There are a few recent trends accelerating the need for unified stack observability.
The Accelerated Need for Unified Stack Observability
Recent computing and application development trends are changing the way Dev, Sec and Ops teams develop and manage their distributed applications across hybrid cloud infrastructures. These changes include the increased use of third-party services, an overabundance of purpose-built security tools and the increasing need to address the shared cloud responsibility model, among others.
An Uptick in Third-Party Code Use
Third-party code increasingly is being used in apps and is one of the critical attack vectors exploited by hackers. SafeCode research notes that 78 percent of companies are running part or all of its operations on open source software, while 66 percent create software for customers built with open source. These stats have nearly doubled since 2010. The very practice of code-lifting, or pulling open source code from different repositories, which has enabled developers to share innovation and collaborate across architectures and levels, is turning to be one of the biggest attack vectors for hackers to exploit. Running on many different functions, open source applications and code borrowed from third-party services increasingly are becoming more vulnerable and therefore require a need for constant observability and monitoring.
Even though such code is usually vigorously tested for vulnerabilities during the build and deploy stages, it can—and in some cases is—compromised in production. The global Magecart credit card skimming incident is an indicator of this: The hackers were able to infiltrate the third-party components and exploited them to gain credit card information, resulting in 800 e-commerce sites being compromised. To avoid such distributed vulnerabilities, Dev, Sec and Ops teams need to constantly index third-party functions and services, and scan for possible vulnerabilities or attacks. Such monitoring requires unified observability at the app code level.
The Growing Overabundance of Purpose-Built Security Tools
Increasingly enterprises are leveraging multiple cloud providers while still running their own data centers, either on-premises or as private clouds. A 2017 report from Forrester Research points to 89 percent of enterprises using at least two clouds, while 74 percent use three or more public clouds. Despite a wide industry effort lead by global leaders such as VMware to provide seamless cross-cloud orchestration and management, most clouds remain in their own environments with a set of purpose-built management and security tools.
Then there is the traditional security approach, which can get in the way. According to Cybersecurity Insider’s “2018 Cloud Security Report,” only 16 percent of organizations believe the capabilities of traditional security tools are sufficient to manage security across the cloud. Eighty-four percent said traditional security solutions either don’t work at all in cloud environments or have only limited functionality, meaning that more tools with specific functionality must be integrated within the cloud. On-premises, private and public clouds remain siloed for most team, stressing an overtaxed security resources across organizations.
Shared Responsibility Can Be a Shared Burden
Even though the shared responsibility model has been well-documented, securing public cloud environments can be a burden to security and IT teams as their responsibilities continue to grow, while available talent is short to find. The traditional shared responsibility model assumes that the cloud vendor secures the hardware and software of the cloud itself, while the customer is responsible for the security of their assets within the cloud.
With the shared responsibility model, most security teams are unsure about how to do their part. Gartner reports that through 2022, at least 95 percent of cloud security failures will be the customer’s fault. This can include anything from a failure to monitor to a failure to adequately secure the correct elements. This can also include customer misconfiguration, mismanaged credentials or insider theft. Additionally, The “2017 IBM X-Force Report” noted a 424 percent jump in breaches related to misconfigured cloud infrastructure, largely due to human error. These gaps in security leave security teams with their organization, data and apps vulnerable.
App-Aware Stack Observability: The New Modern Security Mandate
The biggest distributed security blind spot facing modern Dev, Sec and Ops teams today is for them to monitor for vulnerabilities or attacks at each layer of the stack—at the application/third-party code-use level, their distributed workloads and the network each in isolation. Unified application-aware stack visibility and observability is becoming the only way to fully see and understand potential risks in today’s increasingly distributed environments, effectively addressing some of the biggest security challenges faced by modern Dev, Sec and Ops teams.
Nearly a decade ago, I began working at Amazon as an engineer. Cloud technology was just starting to revolutionize how companies launch applications, and early adopters were seeing the benefits of not having to purchase, provision and manage their own hardware. On the flip side, larger companies (especially those that store sensitive information) were still hesitant to fully embrace the black box that was “the cloud,” holding onto the belief that for critical applications, the cloud was neither reliable nor secure.
Fast forward to today, and all of that has changed. We are seeing government institutions, banks, and hospitals all moving their infrastructure over to the cloud. The benefits of being agile, innovative, and highly efficient have mostly overshadowed the concerns around the cloud’s reliability. According to Cloud Technology Partners, cloud adopters see an average reduction of total cost of ownership (TCO) of around 40 percent. And top-performing banks are 88 percent more likely to implement a hybrid cloud solution than their underperforming peers, cites a recent report from IBM Institute for Business Value.
Long story short, the question is no longer “if” but “which”—and there are three major options: AWS, GCP and Azure. Today, many companies are doing their best to avoid vendor lock-in, opting instead for a distributed strategy, where teams are empowered to choose the best option for what they are working on. While having a hybrid approach helps avoid vendor lock-in, it also can save teams from disaster if one of the cloud providers has a major outage like the great S3 outage of 2017.
But just because you have a hybrid strategy—running active-passive across different cloud providers—doesn’t mean you’re home-free. Unless you’ve actually tested that your passive stack will jump in to save the day in the event of a crisis, you’re more or less closing your eyes and crossing your fingers in the hopes that your active stack never goes down. Think of it like running a fire drill: How can you be sure everything runs smoothly during a time of disaster if you never actually run the drill?
We need to shift how we think about operations to place more of the burden of Ops work upfront. While it’s important to reduce MTTR (mean time to resolution), that still means there has been an incident that has affected customers and potentially your bottom line. As someone who has been a call-leader for Amazon and Salesforce, I know firsthand that we could save ourselves a lot of headaches by being more proactive about running experiments in a controlled environment and focusing on reducing the MTBF (mean time between failures). This is why it is important to have a chaos engineering solution that can run experiments across all of your environments regardless of their build, technology or provider in one simple to use, unified experience. By consistently testing that your “failsafe” actually behaves the way you want it to, you can be much more confident that the operations work you’ve put in to make your architecture more resilient isn’t all for naught when a real-world outage comes calling—and it will.
VMware this week extended its campaign to automate IT environments based on its hypervisors by adding a link capability that enables the VMware vCenter platform to manage instances of VMware vSphere running on-premises and in public clouds such as Amazon Web Services (AWS) and IBM Cloud from the same console.
Mike Adams, senior director of cloud platform product marketing for VMware, said the linking capability added to VMware vSphere will enable DevOps teams to deploy the VMware hypervisor anywhere without having to invest in a separate management framework for each environment.
At the same time, VMware is also updating VMware vSAN storage software that, among other capabilities, adds a self-healing feature designed to minimize disruptions in the event of underlying hardware failure.
Version 6.7 of VMware vSphere and VMware vSAN also now support enhanced client software based on an HTML5 interface that can manage VMware NSX network virtualization software, vSAN and vSphere along with additional third-party products.
Other new features in VMware vSphere include ESXi Single Reboot, which reduces patch and upgrade times by halving the number of reboots required to one, and vSphere Quick Boot, which will skip hardware initialization steps to gain further re-start efficiencies.
VMware is also adding support for persistent memory to speed vSphere performance and adding support for graphics processor units (GPUs).
There’s also now support for both Trusted Platform Module (TPM) 2.0 Support and Virtual TPM 2.0, which serves to protect virtual machines and hosts from being tampered or compromised by the loading of unauthorized components or allowing a guest operating system running on the hypervisor to circumvent existing security controls.
Finally, VMware is making available an instance of VMware vCenter management software running on a dedicated appliance.
Adams said VMware today has 500,000 customers running VMware vSphere, compared to 10,000 that have elected to also run VMware vSAN storage software. The goal for the company is to enable more IT organizations to embrace hyperconverged infrastructure by moving storage software on to the same server where VMware vSphere runs. That approach dramatically reduces the total cost of operations for most organizations, he said.
As VMware makes an arguably belated push into the public cloud, the unit of Dell Technologies is counting on a massive installed base of on-premises customers to move and expand their existing investments in VMware vSphere on public clouds. While there’s no doubt that approach will appeal to significant part of the VMware installed base, many customers have already invested in the hypervisor platforms used by AWS, IBM and Microsoft.
When it comes to lifting and shifting an existing legacy applications into the public cloud, VMware clearly has the inside track. But when it comes to development of greenfield cloud-native applications, VMware vSphere is not often the first choice of application developers, many of which view VMware vSphere as part of an inflexible on-premises legacy IT environment that they deliberately left behind.
To its credit, however, VMware is making significant strides in embracing advanced automation technologies that one day soon might put those developer concerns to rest once and for all.
At the same time, VMware is also updating VMware vSAN storage software that, among other capabilities, adds a self-healing feature designed to minimize disruptions in the event of underlying hardware failure.