devopsy.kinsta.cloud

Tag: cloud-native

  • 3 Common App Modernization Pitfalls to Avoid

    3 Common App Modernization Pitfalls to Avoid

    Application modernization has been a consistent theme for organizations year after year. Businesses today still rely on their legacy applications for the majority of their revenue generation, from mainframes to Java EE. New digital transformation initiatives and mandates have pushed application modernization back to the forefront, as a new generation of automation platforms and best practices are helping these organizations avoid the pitfalls of the past and accelerate their journey to cloud-native architectures.

    Here are the three most common application modernization pitfalls and how to avoid them.

    Lack of a Clear Organizational Destination

    Application modernization journeys need a north star – a destination point that development, infrastructure and DevOps teams can rally around. In order to establish a clear, unified direction, everyone must share a precise understanding of that destination. That journey starts by defining a set of business goals you are trying to accomplish (such as cost savings, business agility, resiliency and/or competitive advantage) that can guide and prioritize the technical decisions.

    Next, you need to decide which application modernization technologies, platforms, and infrastructure will help you deliver on those business goals (e.g., Red Hat OpenShift, Kubernetes, serverless, hybrid, private or public cloud, etc.). Setting common architectural standards will help avoid disparate future stacks and ensure a common shared platform for microservices architectures. For example, if an application starts with Java WebSphere, should the goal be to move to a modern container framework like Spring Boot, or a specific microservices Java framework like Quarkus? To avoid analysis paralysis and internal drag, set tangible objectives and targets that prescribe how teams are expected to prioritize, select and modernize these applications and how their progress should be measured, communicated and shared.

    Taking Shortcuts – Don’t Fall For the Old ‘Lift and Shift’

    The more one modernizes, the more value one gets from the cloud – but not all modernization efforts are created equal. For example, ‘lift and shift,’ putting a monolith into a container and application refactoring into microservices are all called “modernization.” But only refactoring allows enterprises to realize the true benefits of the cloud, including elasticity, regained engineering velocity and cost savings. Don’t fall into the quick-and-easy modernization temptation with lift and shift or brute force containerization. You will still have a monolith, in the end; you’ll simply end up paying more and trading one set of monolithic problems for another.

    Not Bringing Everyone Along – No Developer Left Behind

    Modernization is never just about technology. Modernization requires that your team’s processes (for example, agile practices), structure (vertical domain teams as opposed to horizontal teams – UI team, for instance) and skills must all adapt. The organizational culture needs to grow to adopt DevOps and cloud-native best practices to take advantage of the deep development, build, deployment and operational benefits that are available. Take the time to train and educate so everyone is brought along. Modernizing legacy applications can introduce a whole new set of technologists, responsible for those applications and the supporting infrastructure, into the cloud-native world. This is a win-win for everyone.

    In other words, the organization needs to have crystal clear answers to the where (destination), why (path) and how (team) to ensure success and avoid the three most common pitfalls of application modernization.

  • Ambassador Insights: Cloud-Native

    Ambassador Insights: Cloud-Native

    Cloud-native is a methodology and a mindset that’s been gaining traction in the DevOps and application development space as more organizations look to leverage the benefits of cloud infrastructure, including scalability. As with many other topics in the DevOps space, however, cloud-native isn’t easily definable; rather, it is loosely described by the technologies it utilizes, including containers and Kubernetes.

    In our second episode of Ambassador Insights, featuring DevOps Institute ambassadors Leonardo Murillo, CTO of Qwinix Technologies; Tracy Bannon, senior principal and DevOps strategic advisor and software architect at MITRE; and Pawel Piwosz, lead system engineer at EPAM Systems, we delve into what it means to be cloud-native, look at some of the cloud-native technologies helping shape the landscape and address the security aspects of cloud-native applications and infrastructures.

    The video is below, followed by a transcript of our conversation. Enjoy!

    Transcript

    Charlene O’Hanlon: Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I am here with another episode of the DevOps Institute Ambassador Insights Panel Discussion. I’m so excited to have these on a monthly basis with some very, very smart people who also happen to be ambassadors with the DevOps Institute. And each month, we have a different topic of discussion to align with our monthly spotlight topics on devopsy.kinsta.cloud.

    This month, we are going to be talking about cloud-native and cloud-native technologies, and so, I have some experts in the field right now. First up, we have Leonardo Murillo, who is the CTO of Qwinix Technologies. Hey, Leonardo, thank you so much for joining me today.

    Leonardo Murillo: Thank you for having me, Charlene. I really appreciate it. This is great.

    O’Hanlon: Alright, alright. Next up, we have Tracy Bannon, who is the Senior Principal and DevOps Strategic Advisor and Software Architect at MITRE. Tracy, thanks so much for joining me, we really appreciate it.

    Tracy Bannon: Thanks for the invite.

    O’Hanlon: Great. And finally, last but not least, we have Pawel Piwosz, who is the Lead System Engineer at EPAM Systems. Pawel, thank you, also, for joining me today, we really appreciate it.

    Pawel Piwosz: It’s a pleasure to be here with you.

    O’Hanlon: Great, great, great. So, let’s dive right into the discussion. I know we’ve been talking on devopsy.kinsta.cloud and Container Journal a lot about cloud-native, but I’m not sure, actually, that a lot of people understand exactly what we mean when we say cloud-native, so maybe we should set the stage, if you will.

    Leonardo, maybe you can start us out since you are really focused heavily on cloud-native. Can you kinda tell us what we mean when we say cloud-native? What are we talking about?

    Murillo: Sure. So, I think when we talk about cloud-native, we’re talking about a specific mindset and patterns to apply when we’re building both systems as well as organizations, which is kinda one of the things that I wanted to discuss today, right? Because cloud-native is not just how you build technology, and you don’t really need the cloud to build cloud-natively, right? Usually, when you think in terms of cloud-nativeness, you’re thinking about loosely coupled architecture, you’re thinking about containerization, immutability, statelessness, right? All of these are components that are incorporated in a cloud-native solution, and I think the organization has also to become cloud-native, and that’s where DevOps becomes really important, right? To be able to leverage and really take advantage of all the different qualities, right, that the cloud has basically surfaced and made available, right? What do you think, Tracy?

    Bannon: To extend on that and sort of foot stomp for what you’ve said already and love that you want to talk about the organization, we can talk about, I call it a reverse Conway maneuver.

    Murillo: Right. [Laughter]

    Bannon: [Laughter] So, there’s a lot to be said—I’m actually finding that there’s not agreement on what cloud-native is. There’s an argument—it means containers. Well, yes, and let’s talk about serverless and the impact of serverless. So, it’s not a specific architecture pattern, but it does mean that we are building to take the best advantage of the infinite scalability, right, and the self-healing nature and other aspects of cloud. Love your point as well, Leonardo—while we say it needs to be on cloud proper, building for cloud, right, doesn’t mean that I’m necessarily hosting in an AWS GCP, et cetera and so on. It means that I have applied those principles, and I can do that within my data center, my private cloud, or whether I’m paying somebody else to be the host for me.

    Murillo: Yeah, great point.

    Piwosz: That’s true, and it’s not only about the application, it’s about everything what is around. For example, CI/CD, how we store our code, how we approach to the code, how we approach the security networking. Because this is something that we very often forget when we are going to the cloud, right?

    O’Hanlon: Mm-hmm.

    Piwosz: So, platform as a service, we have everything, we don’t need experts.

    Bannon: [Laughter] Don’t get me started at all!

    O’Hanlon: [Laughter]

    Bannon: But that’s an interesting point is that there are so many fantastic capabilities that are being provided as a service that I don’t think the folks actually know where to begin. I’ve had some awesome infrastructure folks who go out and they do some Googling and they do some research and they come up with a reference architecture. And heaven forbid, but God love them, they go out and spin it up and push the button, and—wow, this is a good solution for my firm or for my client or for my needs—and it isn’t, necessarily.

    So, there’s a lot of trade space that we’re unintentionally losing with the rapidity that we’re moving, trying to move towards cloud. Architecture should be more important, not less important. It shouldn’t be a stalling factor up front, but I jokingly say that, in order to push some value, provide value out into industry or to my clients, I have to be doing that from vision forward, right? I can’t take a steel girder and put it through a wood chipper, right? It’s not going to work because it wasn’t constructed and thought of that way.

    But Leonardo, to your point earlier, as much as the technology to me is the fun and sexy part, the human aspect really needs to be dealt with as well. We talk about it a lot in the DevOps piece of it, the DevOps portion or support effort on it, but you really bring up that cloud-native requires us to think about the organizational structure and building a separate culture than what we’ve had before. I’d be interested in what you think about some of the emerging software factories, or should I say continued proliferation of software factories as the way to move forward on software?

    Murillo: I think that actually talks about kind of a different subject, and I’d like to kinda step back a little and think—because you mentioned something that is very much aligned to this, and it is the whole strategy as to how you approach the cloud, right? It’s not just about click a button and going in, right?

    Bannon: Mm-hmm.

    Murillo: And, to me, that has a lot of resonance to what DevOps is all about, right? If you think into kinda the cada mindset, right, define your North Star first, right, assess your current state, think about it consciously and mindfully, right?

    I think if organizations that are looking to go into the cloud or mature into the cloud do take that step, do take time, they will be able to maneuver this gigantic ecosystem of tools that are out there and technologies that are out there. Because I think there’s also an interesting component that we should discuss. You mentioned, Tracy, how it’s not just about the technology, it’s also about the humans, right, the people that are implementing.

    Bannon: Mm-hmm.

    Murillo: But I think that also resonates with the fact that technology is not there just for the sake of picking the latest and greatest tool, right? I read this great post by somebody that I can’t recall, that basically talked about how boring is good. You know, how boring technology is good because people are used to it and they’re kinda like aware of how it works.

    And I think the closer you are in your evolution path to what is comfortable, the better. And I think that’s one of the problems that I sometimes see in cloud adoption—people try to bite too big of a chunk of change at a given time, right?

    Bannon: Yep. Mm-hmm.

    Murillo: And there’s so much to choose from to make that huge bite. An actually targeted approach that is mindfully defined that is well strategized will solve a lot of these problems, right? Because it will give you a signal amongst all this ecosystem noise that teams are gonna be exposed to, right? So, Pawel, you are kinda like engineering these solutions, right? How do you work around this ultra-diversity of available technologies, right, when you’re building something?

    Piwosz: Mm-hmm. This is … a very big problem. Because right now, together with cloud, we gained much, much more speed with everything, really. So, imagine 20 years ago you had a server room with racks and servers there, so you’d change only the server, but the logical side was still the same.

    Today, we are jumping. Let’s stay with AWS. We are jumping from instituting analysis to microservices, then to serverless microservices, then to serverless itself. Who knows what we will find next year, for example, right? You need to switch your mindset here. This is something that especially all kinds of CisOps—well, I am all kinds of CisOps—people have in mind, right? The same for networking, for security. There is a huge difference in speed here.

    So, you need to incorporate into your mind things like do fast, fail fast, learn fast—especially learn fast, because we are forgetting about this very often; too often, I would say. And also, we are forgetting very often in the trenches about the security of the cloud.

    Bannon: Oh, gosh, yes.

    Piwosz: Because—yes, because we’re saying, okay, we have a shared responsibility model, so they are responsible for everything. We’re just running our application and not caring about anything else, what is really, really wrong, I believe.

    Murillo: And I think that points to a fundamental misunderstanding, right, of what security in the context of cloud native architecture is all about, right? And I also think about, Tracy mentioned this infinite capacity, right? And you mentioned, Pawel, going fast.

    I’ve been thinking a lot recently as to how those two components need also to be very effectively managed.

    Bannon: Yes.

    Murillo: By leadership, by those that are sponsoring these initiatives, right? Because after all—and this is something that I’ve been talking about lately, right? We have optimized for speed alone already without having, really, awareness of the impact that that would have on the environment and many things, right? And I think we really need to establish a mindset where engineering teams are aware that infinite capacity doesn’t mean just free for all, grab whatever amount of resources you have, that shared response security is not infinite, overwhelming security, right?

    And I think this is also relevant in the context of the tooling that we were talking about, right? Everything now is available kinda point and click. You download a package, you have an appointment. You download another package, you have authentication and connectivity, right? And we don’t go into details necessary to understand kinda the supply chain of all these solutions.

    So, I think that’s where—the mindset of DevOps, right, reduce waste also becomes very relevant, right? Just because you have infinite capacity doesn’t mean you can’t be wasteful or you don’t have to be constantly evaluating the outcome of your ongoing efforts, right? Yeah, so, I think that’s very important.

    Bannon: There’s a treasure trove of topics that you just landed on, so it sounds like it could be a longer collaborative.

    O’Hanlon: Yeah, right. [Laughter]

    Bannon: So, in terms of reducing waste, one of the things that I’ll put out there is that I believe, in what I’ve observed with teams that I run or teams that I’m reviewing the content is that some of the cloud capabilities have made us, I think, lesser programmers, lesser developers, because we’re not concerned about the same things that we were before. We’ve delegated authority or we’ve delegated that concern.

    I’ve seen some pretty hideous, performance-wise, if I were to run it anywhere other than being able to up my compute, it used to be that we had to be concerned because it cost a lot to add additional resources, right? If it wasn’t as performant as we needed it to be, you just threw more hardware at it. That went away for a long time because it was cost-prohibitive.

    We’ve almost gone back and revisited that in some ways. From a security perspective, it’s always been my perspective that it needs to be baked in. It has to be part of the ecosystem. So, when folks started talking about DevSecOps, I was actually against that, because DevOps means that there’s a security part of it, but I do understand that it was, at times, not thought about. Our developers need to be educated, but they need to be held accountable because it becomes—there is a group effort. Now, when I say developers, I mean the athletes who are hands-on, they’re engineering with us, they’re moving the software forward.

    But there are two pieces that come to mind with this. There’s a limit to how much they can consume. Mentally, there’s a limit to how much they consume. I’m looking at Pawel’s background and I’m thinking to myself, “I love all the stickers” and yet, those are all the technologies that he’s considering that he’s looking at. So, as leaders in technology, one of the things that we need to do is to provide guidance to the folks who are on our teams to help them reduce the noise. It doesn’t mean to ignore the new things, but it does mean go ahead and get to finish, get to done on one thing, get it working, learn from it, and then improve it. And if improving it means that there’s a certain amount of acceptable refactoring or pulling in another tool—absolutely, right? That’s technology insertion, that’s a good, smart thing.

    But it does also mean that we don’t instantly glom onto everything that’s coming along. I have one organization in particular where every team is allowed to have the autonomy and latitude and I’m just there as an observer, and it’s a little bit of melee. There are lots of good pockets of interesting things, but because there’s such technical diversity even in a small space, they’re having a hard time, because they’re not able to get crisp and good and deliberate with the first set of tools. To your point earlier, Pawel, they’re not getting good enough with what they’re doing before they’re switching on to something else.

    So, cloud native mindset is pretty important, but helping to folks understand cloud native from a, what is it from a patterns perspective, what are the architectural tradeoffs for it, and then helping them to make selections and stick with it long enough to get a success, I think, are really keys to helping organizations.

    O’Hanlon: So, do you guys think that cloud-native is kind of an all-or-nothing proposition? Are organizations—have you seen organizations kind of going all-in on cloud-native and then maybe pull back?

    Murillo: I’ve seen them going all in and I’ve seen them crash and burn. [Laughter]

    Bannon: Yes! [Laughter] Alright, then!

    Murillo: Yeah, I think—I was talking the other day as to, everybody knows juggling is really good for the brain, but if you try to learn to juggle with your most precious items, you’ll never learn because you’re gonna be very afraid.

    I think it’s the same about cloud and DevOps, right? Everybody knows it’s great, everybody knows there’s gonna be a lot of value out of it, but if you try to learn it with your most precious things—for instance, your entire organization—you’re gonna have a lot of resistance to getting it right.

    So, I think the same applies for DevOps and cloud-native. I think you need to iterate. You need to start small with projects that you’re capable of experimenting with, right? Kinda like the whole concept of a culture of experimentation and iteration is important, right? But there’s gotta be awareness to the fact that you cannot just experiment with everything, right, or with everything at the same time.

    So, what I mentioned, right, bite small pieces at a time, iterate, do concepts, and use those concepts to build kinda your operating model, right? What does a cloud mean to you for your organization, right? And then expand up until you have a very solid framework that is well establish, well understood, and then you can kinda start juggling with fire, but not until then.

    Bannon: That also helps us think through greenfield versus brownfield. I deal a lot with governments and a lot with federal governments and different agencies in defense. And there’s a tremendous amount of brownfield. It doesn’t mean that there’s old brownfield, but it means that there’s something pre-existing, so there have to be decisions made about where do I add on the cloud-native? Do I do it around the edges, is it incremental, am I doing strangler fig tree patterns, et cetera and so on? That’s one piece of it. Net new sometimes is a good place to try cloud-native, right, because you do have perhaps less confines around it, so take something smaller that’s greenfield and make your first foray that way.

    I think it’s an interesting conversation about the starting and stopping points for cloud-native? I noticed—and I’d like to hear, Pawel, if you’ve seen the same thing—I saw everybody lift and shift as quickly as they could. “I wanna get rid of my data center, so I’m just gonna move my workloads, right? IAS, I’m gonna move my workloads.”

    So, they moved their workloads, and I naturally thought the progression would be to pass or would be to cloud-native and to the refactoring. What I actually observed was a pendulum swing to the analytics side. And so, there was a tremendous, I have all of this compute available to me, I have less expensive storage, I’ll move over to the analytics side, and we’re just starting to see, a real increase in the cloud-native application space. Unless you’re truly talking about upstarts and greenfielding, there has been much less of it with the brownfield and the incremental improvements.

    Piwosz: Yeah, I agree with you. So, first of all, if you just do lift and shift to cloud, whatever we call the cloud, you will cry very soon. So, this is the first thing.

    The second—yes, we have a lot of possibilities regarding analytics, we have beautiful words right now, buzzwords like observability, telemetry, et cetera, et cetera. So, we’re just expanding our monitoring, let’s say old-fashioned monitoring to the new areas and collect more and more and more, and more structured things.

    So, this is something what is very, very easily achievable, but also—and this is in relation to the previous topic here, if you start with cloud, well, you are already in the cloud. There should be still a logic behind everything. Because, today is so tempting, because you do not have to do the initial investment, right? You just click a button and start using serverless or just create a big, big cluster of something, right?

    And then, in my work, I observe this multiple times, then you create a crazy, really crazy solution for a very simple thing. Well, what can go wrong in this, right? So you are using like 10 or more technologies which are completely different, you are trying to wire them together and then you are saying—okay, I know 20 technologies, it looks perfectly well in my CV. But when you talk with people, you just realize that it doesn’t work as it should work, really. That’s why, very often, organizations which are going to cloud and do not take logic in this, how it is organized, how it is architected, how this even developed, they are paying much, much more, not just because they did lift and shift, but they started to create very, very crazy solutions, right? And this is the kind of waste that you mentioned as well.

    Bannon: I’m gonna throw out just a couple quick words that’ll make people cringe, but when I think about—so, agility 20 years ago, right, the agile manifesto, there’s a woman named Linda Northrop from the Software Engineering Institute at Carnegie Mellon who said it was one of the worst things that ever happened to software architecture, because unintentionally, there was this emergent architecture, my architectures will just emerge, I don’t have to worry about them in advance. I want to push forward that enterprise architecture needs to still exist, but in a different form, in a different format. There still needs to be, it’s okay for there to be somebody more senior, somebody who is helping to drive the architecture and helping to pick which cloud technologies and where cloud native is the most appropriate.

    Because there’s different trade space, right? Even if I talk containers, there’s different trade spaces between how I’m using the containers and how I’m moving forward with that. Does that resonate with you, Pawel and Leonardo?

    Piwosz: Yes, yes. I would even add here that if you want to be cloud-native, your developers need to be cloud-native. So, there is no more, “It works on my machine”—this is obvious, right? But also, I will be bold here, so even development should go into cloud. And this is another layer here, which we didn’t touch, but it is very important, I believe.

    O’Hanlon: Well, I feel like we could have this conversation for at least another hour, but unfortunately, we gotta wrap things up, guys. But I do appreciate Tracy and Pawel and Leonardo for your insights. You guys are great. I’m gonna have all three of you back on and we’ll talk about other things in the future. We have lots of topics to get through this year.

    The level of intelligence and insight you guys bring to these conversations is just so, so value added, so I do appreciate your time in joining me today for another one of our DevOps Institute Ambassadors Panel Discussions. So, thank you, guys, again. We really do appreciate it, and please do stay in touch with me. I’d really absolutely love to get your expertise back on the show, so.

    Bannon: Alright, fantastic. Be well. Stay safe, everybody.

    Murillo: Thank you very much.

    Piwosz: Thanks, everybody. Thank you.

  • Moving Legacy Applications to the Cloud

    Moving Legacy Applications to the Cloud

    Even in 2021, many companies still run business-critical, legacy applications on-premises, just as they have for the last 20 to 30 years.  The midrange server hardware, and their unique architecture, on which many of these applications run is both their biggest drawback and biggest advantage; the benefits of being able to vertically scale a platform were measured against the drawbacks of the necessary custom hardware. Migrating the workloads running on these types of systems to the cloud, which can potentially offer huge benefits, presents some unique challenges – here are four strategies for doing this, with pros and cons for each.

    Option 1: Lift and Shift

    The “lift and shift” option means you’re simply representing the on-premises network within a cloud service provider. This is the easiest and quickest option.

    Until recently, this was not an option for most legacy applications. This was because the main hyperscale clouds did not offer dedicated infrastructure as-a-service (IaaS) implementations for several common data center operating systems. The process required purchasing a vast amount of dedicated hardware to offer as-a-service to customers, and it wasn’t clear if the demand warranted that cash outlay.

    Recently, however, it’s clear that the only way for organizations can leave behind the data center is by moving business-critical applications to the cloud. There are now hyperscale cloud providers that offer lift and shift options for even the most demanding workloads.

    Despite these benefits, it’s important that a lift and shift approach is carefully planned before executing. Even a couple of seconds of downtime in traditional application workloads can cost businesses thousands of dollars. Finally, organizations should understand that they won’t be using the cloud to its full potential simply by recreating their on-premises environment.

     Option 2: Rewriting or Refactoring

    Refactoring a traditional application into a cloud native application has been the de facto migration option for many years. It provides greater long-term cost savings than other options, because previously underprovisioned data center resources can now be consumed on-demand in the native FaaS offerings of hyperscale cloud providers. The compute capacity is nearly limitless, and only scales as resources are being used.

    However, refactoring to cloud native services does have major risks, such as high short-term costs. Refactoring an existing business-critical application is typically much more complex than a simple lift and shift. Also, an application that has been part of the core business stack will have likely accrued many dependencies and interfaces with other systems and added modules that must be accounted for.

    Another consideration is that legacy interfaces must appear identical to other systems post-migration, otherwise you must expand the scope — including other systems in the migration project that originally weren’t planned. Many of the hyperscale cloud providers do not support legacy interfaces in their cloud native services. Scope creep can become a real issue in this scenario, and your organization could lose sight of the migration timeline.

    An enterprise service bus (ESB) is one potential solution to the problem of legacy interfaces. An ESB is typically deployed as a “bus” between various business applications, ensuring that all those interfaces use a common interface. The ESB handles the network, transport, routing and delivery of messages and content. However, ESBs add yet another layer of complexity, increasing the risk of failure for the overall refactoring project.

    Option 3: Dynamic Lift and Shift (Reshape)

    Reshaping an application to the cloud typically lies somewhere between the lift and shift and the refactoring strategies. It’s similar to lift and shift, but usually involves some minor modification to the application to take advantage of native tools within the cloud infrastructure. An example is adding automated launch and tear down of development and test environments.

    One of the main advantages of a reshaping is that it is cost-effective. An organization will see significant cost savings over a simple lift and shift, for example, by only having to pay for the hours that the development and testing machines are powered up and running.

    It also means that the development teams are free to experiment with refactoring certain applications without a hard deadline (such as a data center exit.) Finally, a dynamic lift and shift strategy allows development teams to leverage cloud native functionality, such as infrastructure as code, to automate traditional workloads without retraining on a whole new development stack.

    Option 4: Drop and Replace with COTS

    Another option is to replace your custom application for one that is commercial off the shelf (COTS). For example, replacing a custom-built customer relationship management (CRM) system with a vendor’s product.

    This is not feasible for some organizations because of their business environment constraints, but it is recommended when possible. COTS products (that are typically SaaS) usually have a repository for various connectors to different legacy applications; however, this is largely dependent on the size and maturity of the COTS product.

    It’s important to note that one of the largest risks of considering a COTS application is the skills within the organization. If the current development team’s skillset lies with custom, traditional applications, they will need extra time to retrain and develop the extensions to integrate the COTS product with their existing environment.

    Migrating any application to the cloud is a large undertaking. There will always be risks when moving existing on-premises applications to the cloud, but in general, the overall positive impact of moving legacy applications far outweigh any risks, regardless of the approach you decide to take.

  • Why Boring Tech is Best to Avoid a Microservices Mess

    Why Boring Tech is Best to Avoid a Microservices Mess

    Microservices are all the rage. A Forrester study found that 76% of enterprises were rearchitecting applications for microservices.

    At the same time, microservices are definitely not a silver bullet. Among those already using microservices in production, one study found that 59% said each microservice added increased operational challenges such as data management. Even more concerning, the same report revealed that when asked to compare the difficulty of troubleshooting different environments, 73% said microservices were more difficult, and only 21% said they were easier than monoliths.

    But how did we end up like this? According to Matthew Sinclair, VP of engineering at BCG Digital Ventures, it is because that, as technologists, “we want to use the most modern tech, and sometimes we even want to do it with tech we’ve got no experience in. We see this with engineers, not because it’s the right thing to do but because they want to learn something new.”

    Sinclair, who was speaking as a part of an Indorse Engineering Leaders Online Panel, went on to point out how the problem becomes self-perpetuating: Customers hear about new tech—in this instance microservices—that will fix the problems they have with monoliths. They rave about microservices to software engineers, who also get excited about it and then go off and start adding microservices in software engineering projects.

    The problem is, there is just as much chance of getting into a tangle with microservices as there is with monoliths. That’s because people often start breaking things up into microservices too early—they’ve heard it will be a good idea and they’ve seen some of the benefits, so they try to apply it to everything. In doing so, they create what some might call a “micromess.”

    Avoiding the Micromess

    So, how do you avoid ending up in a micromess?

    You need to go back to the fundamentals. One way to look at it is understanding that microservices are distributed systems, something many people will have experience with. They should also be familiar with what another panelist, Oswaldo Hernandez Perez, engineering manager at Improbable, called the first law of distribution: “If you don’t need to do it, don’t do it.”

    So that means focusing on why you are building what you are building. What are you trying to achieve? This is a fundamental question that’s applicable to businesses of all sizes. What problem are you trying to solve, and how will your solution remove friction from its users’ lives?

    That’s what people care about. Even if you’re developing a niche app for a highly technical audience, they are unlikely to care too much about how it got to them, only that it did and it is fixing a problem for them.

    If the only way to achieve that is with microservices, then yes, you should definitely use them. If there is an alternative, then consider using that. Do not simply start breaking everything up into microservices just because that is what everyone is currently talking about.

    Don’t Stick Your Head in the Micromess

    Ultimately, microservices are an architectural pattern to reduce complexity. It does this, but it also adds complexity elsewhere. If used in isolation, then you’ll fix your complexity in one dimension and have it proliferate elsewhere. So, it is vital that you use the many other tools out there to minimize complexity across the entire organization.

    It goes back to the question: What problem are you trying to fix? The majority of businesses can do that with boring tech. Granted, the likes of Amazon and Google, which are cloud-native to their core, can use microservices, but even large enterprises should be asking themselves if it’s really the right choice for them.

    Established businesses are likely to have a significant legacy codebase, which needs integrating with. Again, microservices might not be appropriate in this situation—it might be worth saving them for cloud-native projects, and use boring tech to resolve the challenges within legacy IT.

    Do You Really Need Microservices?

    Time and time again, we come back to the fundamental question: What are you trying to fix with this product and/or technology? Not how, but what? What friction will you banish from the user’s life if they engage with your product? Only once you answer that question should you consider whether microservices is for you. Chances are, you may find you don’t need them by that point.

  • How to Build a Highly Qualified Cloud-Native Team

    How to Build a Highly Qualified Cloud-Native Team

    If you’re reading this, you more than likely are aware of the struggles involved in recruiting and building a team of technical professionals skilled in cloud-native computing technologies such as Kubernetes, Helm, Prometheus and service mesh. The Linux Foundation and edX’s “2020 Open Source Jobs Report” found 93% of hiring managers are having difficulties filling open positions that require open source skills like these. The report also found that cloud and container technologies are the most in-demand aside from Linux, which itself is a necessary basic skill for cloud professionals.

    So the question is, between a talent shortage and rapidly increasing adoption of these technologies, how can any leader manage to build out a qualified team? Based on our experiences as a vendor-neutral provider of training and certification for many of these technologies, we’ve learned some tips and tricks that, with some effort, can help you establish a team that can handle any cloud-native project you throw at them.

    Don’t Rely on the Same Old Recruiting Strategies

    It’s important to understand that the most promising cloud developers, engineers, administrators and other team members may not have the most prestigious qualifications. You may often find a high school dropout who has completed a cloud computing bootcamp and passed a Kubernetes certification exam will be far more able to perform the functions of a job than a recent graduate with a computer science degree. This means you need to set the job qualifications appropriately.

    If your organization is going to limit these hires to those holding a college degree, you are reducing an already limited talent pool even further and you’re going to miss out on some incredibly talented individuals. Instead, look at demonstrable skills and experience rather than only education. Some of the most talented contributors to these open source projects themselves don’t hold degrees; if the people building these technologies don’t need one, then neither do the ones implementing and administering them.

    Of course, you should continue to look at candidates with computer science degrees—after all, you’re trying to expand your access to talent, not reshuffle your sources. College degrees are a valuable indicator of intelligence and tenacity in completing a rigorous program. But do not take the degree as evidence they can perform any cloud-native tasks. Look at their specific skills, what the university curriculum was, any external training or self-study they conducted and verifiable credentials.

    Structure job postings as a list of skills and abilities necessary to be successful in the role rather than specific educational requirements or years of experience—in fact, many of these technologies are so new that no one has more than a year or two of experience with them. Avoid absolutes where possible and encourage folks to apply even if they don’t check every single box. And if you do want to ensure that someone is up to the challenge, you can require they hold verifiable certifications. The trick here is to find the certification most respected in the industry for a particular skill set, and prioritize performance-based certifications that test abilities to knowledge-based ones that only test memorization.

    Go Where the Developers Live

    Do not expect a wave of great applications just because you throw a well-crafted job posting on the internet. Many of the most talented cloud-native pros out there don’t bother looking for opportunities as they are already constantly bombarded with them. You need to find them where they are spending their time, which is likely message boards and forums such as StackOverflow and Reddit. LinkedIn can sometimes be effective, but experience shows this type of expert is less likely to spend time there than individuals working in many other professions.

    And do not simply bombard these professionals with job opportunities, either. You need to make your organization stand out and demonstrate why they should want to come work for you. The Open Source Jobs Report asked opens source pros what would make them consider moving jobs—while to no one’s surprise salary is a top incentive, 65% stated the opportunity to work on interesting projects would tempt them, while 58% desire a better work-life balance and 51% want more flexible schedules or telecommuting options.

    Talk these up in your outreach, but you should also put your money where your mouth is. Sixty-three percent of the hiring managers surveyed this year said their company has decided to contribute to an open source project, either financially or by contributing actual code, for the express purpose of attracting developers who work on that project. If your organization is using open source technologies but not giving back to the community, you will miss a significant opportunity to raise your profile among target recruits.

    Take a Chance and Help Them Grow

    Let’s say your company is participating openly in open source, being a good community member, offering competitive benefits, being open to considering individuals from a broad range of backgrounds and advertising your open roles in ways that both get in front of and attract talented cloud-native professionals. Despite all this, you still have not been able to recruit enough talent to tackle the needs of your organization.

    The first recommendation when you’re at this stage is to look at your existing resources: Are there talented individuals in your organization who do not possess the skills necessary to perform these tasks but possibly could with the proper training? If so, give them the chance to grow into such a role. You can start off with very little risk involved; ask them to complete a free introductory training course and report back after. Consider how long it took them to complete the course and ask them how they feel about this type of work. It should be apparent quickly who is enthusiastic and excited about learning a new technology and who is not. You can then sponsor those who show promise for more advanced training courses and certifications to demonstrate they have gained the necessary skills to move positions.

    If you don’t have anyone internally who either can or wants to train for a cloud-native role, look at recruiting someone with promise and make clear from the start that the expectation is they will complete training and gain an appropriate certification within a specified time period. Look for individuals who have already demonstrated both grit and an ability to learn. Perhaps they have an entry-level IT certification that is far from meeting your requirements but still shows that they can complete this kind of program. You’ll find many candidates are strongly enticed by such an offer.

    This is reinforced by the data from the Open Source Jobs Report: 54% of developers surveyed stated that lack of employer-sponsored training is a major hindrance to their job and 70% stated that increased training would make them more effective. 70% of hiring managers also stated that they’ve seen more requests for training from employees the past year.

    Summary

    We know it’s a tough job finding qualified cloud-native talent to fill open roles, and it is not expected to get easier anytime soon. By putting in a concerted effort, being thoughtful and flexible about the types of applicants you consider and giving existing and potential employees the opportunity to grow into these roles, you and your team can be successful.

    This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America

  • From ‘Cloud Zombies’ to Multi-Cloud Experts

    From ‘Cloud Zombies’ to Multi-Cloud Experts

    A significant risk associated with cloud migration is overspending. For years, zombie-like obedience to AWS has resulted in price lock and escalating fees at many organizations – this is a tale for fighting the cloud zombies.

    Cloud costs around data egress or application bandwidth are often not transparent and thus highly unpredictable. Complicating this problem is the need to rapidly develop and scale large application ecosystems, leading to snap judgments by project engineers to buy tools. Or, cloud purchasing decisions fall to the CFO, who may not be qualified to understand technical nuances. Without cloud spending forethought, it’s easy to enter unsavory pricing commitments.

    However, all of this is changing. As cloud service providers (CSPs) mature their offerings, competitors have risen to take on AWS, unlocking more consumer choice throughout the cloud landscape. In a multi-cloud world, cloud economists are leveraging lift and shift capabilities to optimize performances. Ironically, companies are also seeing cost benefits in retaining some on-premises servers.

    I recently spoke with Scott Leatherman, chief transformation officer at Virtana, to get his take on preventing cloud cost escalation and how IT should streamline multi-cloud environments to stem the cloud budget.

    Zombies in the Cloud

    When the cloud arrived, it promised high performance at a low cost. Companies were happy to offload on-premises servers for the ease of cloud arrangements. For years, there was a “zombie-like loyalty” to cloud platforms, said Leatherman.

    Not much was thought about costs rising in parallel with the astronomical growth of the web, mobile and IoT. Executives penned long-term pricing contracts without a second thought. Then eventually, reality hit. And it came with a hefty price tag.

    Spooky Cloud Expenses

    As cloud-enabled businesses took off, they encountered many hidden fees. To name a few:

    • Egress: Fees for moving data in and out of the cloud.
    • Application: Fees for moving applications to new instances.
    • Workloads: Mounting costs for increasing bandwidth and workloads.

    These and other add-ons could quickly raise a cloud bill from $200 to $200,0000 a month. Complicating this was the fact that many large organizations purchased multi-year cloud subscriptions locked at a specific price.

    Counterintuitively, such cost-savings guarantees are “completely backward,” Leatherman said. As computing power increases exponentially per Moore’s Law, servers become cheaper to maintain.

    “You’ve literally committed yourself to something that is depreciating in cost,” he said. Yet, those savings don’t trickle down to consumers and SLAs have remained pretty flat. “What’s the most frustrating thing for me is that the best way to run this business is to lock people in.”

    The Zombies Become Aware

    In the wake of COVID-spurred digital transformation, cloud zombies are waking up to slash the budget, finding cost-effectiveness in multi-cloud strategies. Some companies are even reaffirming ties with on-premises servers.

    If performance isn’t worth the cost, it defeats the benefits of moving to the cloud entirely. So, how can we smartly optimize our environments for quality performance with leaner financial margins? Leatherman shared some steps to become cloud-smart:

    1. Baseline Your Footprint

    The first step toward reducing cloud costs is maintaining a baseline of all cloud dependencies and private data centers. This should cover a deep cost and performance analysis.

    “You need a baseline in your data center—what can I move? what should I move?” said Leatherman. Unless you have a baseline of what your data center is doing (both private and public), you can never understand what resources should move to the cloud. Powerful apps for monitoring the public cloud could help audit architecture.

    2. Optimize, Optimize, Optimize

    Only after mapping topologies can you can begin to optimize performance. Since usage differs depending on the season, cloud optimization should respond to yearlong application usage trends. For example, ERP software may pull significantly more requests at the end of the quarter and e-commerce spikes during the holidays.

    Organizations should ensure the elastic cloud truly scales to application needs, but only when needed. Ensure systems of orchestration and routing function properly, and diligently search for hidden fees. “The cost that sneaks up on you in the elastic cloud always comes up,” said Leatherman.

    Heavy computation processes, such as machine learning over big data, will require enormous server consumption. For resource-intensive scenarios, Leatherman recommended keeping code lean. Whereas CPU relies on the laws of physics, “application developers are only limited by creativity,” he said.

    Application developers should whenever possible optimize code to avoid redundancies. Doing so yields a positive environmental impact, too—eliminating operational inefficiencies can decrease cloud server usage, which reduces carbon footprint.

    3. Lift and Shift

    GCP, Azure, Oracle and other CSPs mature, the zombie-like loyalty to AWS is fading. “Now that there is parity across cloud vendors, things are changing,” he noted. “The flexibility in the marketplace is really dynamic.”

    In a multi-cloud world, organizations can leverage a hybrid cloud and “lift and shift” toward the best cost optimizations for their specific needs. This is where maintaining a strong baseline will help continually test cost efficiencies among cloud competitors.

    4. Refine Your Tool Procurement Process

    Another solution involves scrutinizing your cloud procurement process and the personnel involved. As mentioned above, new cloud tooling purchasing may occur at the DevOps level or large contracts may be escalated to the CFO office.

    Unfortunately, neither side is in an ideal situation to make smart financial decisions—one faces an urgency to deliver and the other can’t see the trees from the forest (and especially not the termites eating the valuable wood). Many believe a new role is required—The Other CFO—to help optimize the cloud stack.

    5. Retain and Optimize Private Data Centers

    By now, most enterprises are accustomed to having both a data center and a cloud center team. Leatherman argued that ultimately these two teams must work together to avoid outages and reduce the exponential costs of moving to the cloud.

    From a security perspective, there are still significant advantages to maintaining on-premises private clouds and data centers. By leveraging private assets, you aid data protection efforts and have increased control. “Datacenters have value,” he said. “Unless you started there, no one will be 100% cloud.”

    Although cloud migration seems inevitable, through software automation and Moore’s law there is value in on-premises. As a result, Leatherman predicts a rise in private cloud data center optimization and management services by third parties.

    6. AI for Cloud Cost Awareness: DevFinOps

    Finally, AI soon may be available to automatically scan for cloud cost impacts before applications are even deployed.

    Most DevOps teams use container security scanning or automated compliance validation as part of their DevSecOps process. Leatherman suggests future DevOps tooling will similarly evolve to display automated notices that estimate cloud costs for your actions in real-time.

    For example, as engineers are pushing code, a popup could display server utilizations and a cost impact breakdown. Or, inline code validation suggestions could find redundancy to decrease waste. Perhaps we’ll need a new abbreviation for this Developer + Finance + Operation focus—DevFinOps, anyone?

    Such an AI would likely not negate the need for a cloud economist to help manage multi-cloud complexity. “We’ll still need them,” said Leatherman.

    Surprises in a Multi-Cloud World

    COVID–19 is accelerating deployments tagged for much shorter timeframes, forcing many more instances to public clouds. Businesses need to get performance up and meet their SLAs. To reduce expenditures, they must quickly lift and shift to the most performant and cost-efficient environments.

    The gravity is apparent, yet hasty moves now could be disastrous for security and data privacy in the future. Besides rising cloud costs, there are other risks associated with the cloud that increase exponentially with multi-cloud environments. “It’s not just the financial spend, but the security and risk that goes along with it,” Leatherman said. “It becomes really scary how many people have access.”

    Not only must cloud spending decisions shift left, but security must arise earlier in the development cycle as well. Compliance with regulations such as GDPR or HIPPA should also influence how teams manage data between clouds.

    The Cloud is Relatively New

    An IBM-endorsed study found enterprises are only 20% of the way through their cloud journey. Many enterprises are still just at the beginning of their cloud transformations, and 90% plan to expand their cloud footprint in the next year.

    The cloud journey is quite long, and many have quite a way to go. Knowing this, cloud economics will only rise in importance. As I recently covered, cloud expertise is now superior to a university degree.

    Current forces, like the COVID–19 crisis, will no doubt continue to “drive people to the cloud,” said Leatherman. While responding to the imperative to deliver more and higher speeds, it’s essential to be smart, leverage existing assets, and optimize cloud usage at every level possible. “It shouldn’t just be cloud-first,” he said. “It should be cloud-smart.”

  • Operationalizing Cloud Native with Kubernetes Virtual Summit Speaker Spotlight: Tracy Ragan, Cornelia Davis, Ashley Ward and Rob Hirschfeld

    Operationalizing Cloud Native with Kubernetes Virtual Summit Speaker Spotlight: Tracy Ragan, Cornelia Davis, Ashley Ward and Rob Hirschfeld

    The Operationalizing Cloud Native with Kubernetes Virtual Summit will bring together Kubernetes and cloud-native community members for a unique learning experience focused on the tools and best practices you need in order to successfully secure and manage Kubernetes. Presented in a virtual reality environment, the event will take place on Oct. 1, at 10 a.m. EDT.

    Operationalizing Cloud Native with Kubernetes - speakers - Tracy Ragan - Cornelia Davis - Ashley Ward - Rob Hirschfeld

    At the The Operationalizing Cloud Native with Kubernetes Virtual Summit, Kubernetes technologists, DevOps and cloud-native experts will be educating the audience on cloud-native technologies and digital transformation with Kubernetes. Tracy Ragan of DeployHub, Cornelia Davis of Weaveworks, Ashley Ward of Palo Alto Networks and Rob Hirschfeld of RackN are a few of the outstanding speakers that will be sharing their knowledge and insights with the community at the Operationalizing Cloud Native with Kubernetes Virtual Summit.

    Recognized as a Women In Technology (WIT) Honoree for her work in DevOps, DeployHub Co-Founder and CEO Tracy Ragan is an expert in configuration management and pipeline life cycle practices with a hyper focus on microservices and cloud-native architectures. Tracy is a well-known DevOps evangelist and DevOps Institute Ambassador. She serves as board member of the CDF, where she is the elected General Member Representative, and she is also the creator of the Continuous Delivery Foundation Interactive Landscape. Prior to DeployHub, Tracy was co-founder and COO at OpenMake Software.

    During her talk, “Achieving Business Agility with Microservices,” Tracy will explain what application teams must do in order to achieve business agility. She will explore how microservices are truly the last mile of Agile practices and an essential component for the creation of a modern software architecture.

    One of our most distinguished speakers is Cornelia Davis, CTO at Weaveworks and author of “Cloud Native Patterns: Designing Change-Tolerant Software.” Cornelia is an industry veteran with almost 30 years of experience in image processing, scientific visualization, distributed systems, web app architectures and cloud-native platforms. She is responsible for Weaveworks’s technology strategy, inclusive of open source projects, commercial products and services offerings. Cornelia is driven by the desire to help enterprises transform their business through the leverage of cloud computing platforms.

    In her session, “The Business Benefits of GitOps,” Cornelia will cover key GitOps principles and practices and tie them to measurable IT outcomes, such as change failure rates and mean time to recovery. These IT metrics are intrinsically tied to digital transformation initiatives. She will also review research that has shown a correlation between these measures and where companies fall on the spectrum from high to low performers in terms of business outcomes.

    Ashley Ward, CTO for Prisma Cloud at Palo Alto Networks, is another of our brilliant speakers presenting at the virtual event. Ashley aids customers in the secure deployment and scaling of cloud native environments. He has over 15 years of experience in the operations and infrastructure architect space.

    During the session “Kubernetes Security – Defense in Depth,” Ashley covers the areas that need attention when securing the Kubernetes stack.

    “Kubernetes can seem complicated and even frightening when trying to secure it,” said Ashley. “I hope that people takeaway an understanding of why and how they can secure their Kubernetes clusters and resources.”

    He will also introduce the audience to the concept of a cloud-native application protection platform.

    Another DevOps and cloud-native expert joining as a speaker at this year’s virtual event is Rob Hirschfeld, founder and CEO at RackN. Rob has been creating software to automate infrastructure for over 20 years. He has been involved in numerous open source efforts including LF Edge (Board), CNCF (SIG Chair) and OpenStack (Board).

    Rob will show how EdgeLab.digital uses Digital Rebar to provide PXE boot, immutable O/S and API-driven automation control of RPis to build Kubernetes (k3s) and OpenFaaS.

    “This session is a ground-up demo of the entire process and background about why it’s important to have a proven reference architecture,” said Rob. “This is designed as a learning environment that can also scale to real edge and enterprise use.”

    Attendees will learn how this easy-to-duplicate-at-home demo creates a true desktop data center using the community edition of Digital Rebar to enable netboot for RPis and install CNCF sandbox project K3s. The same code learned in this demo session can run any COTS infrastructure and is currently running multinational banks in the EdgeLab.

    You can hear from these speakers and more than 30 other industry leaders at Operationalizing Cloud Native with Kubernetes Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Operationalizing Cloud Native with Kubernetes Virtual Summit website.

  • 3 Ways To Tackle the Operations Complexity of DevOps

    3 Ways To Tackle the Operations Complexity of DevOps

    DevOps is challenging, some of its complexity requires a platform that is both SaaS and managed environments, running on top of several cloud providers and potentially on-premises as well. Is there a platform that connects applications and systems while supporting enterprises as they accelerate their digital transformation efforts? If done the traditional way, you have all the ingredients to fall into an operations nightmare. Unless you tackle the challenges with cloud-native approach from day one.

    Let’s explore three ways to tackle the operations complexity of DevOps.

    Cloud-Native Architecture

    Why use Kubernetes? This technology is an open source system for automating deployment, dealing with massive scale and management of containerized applications. If the main initiative is to isolate every single integration that runs, then select an architecture component that could give you a head start.

    A well-designed application based on microservices and running on containers can benefit heavily from technology such as Kubernetes in the following ways:

    • Resilience & Fault Tolerance: These are key ingredients for today’s highly available, always-on systems. With the help of Liveness and Readiness probes, we can set up an environment where any misbehaving container could be automatically recycled and have a new instance ready to use.
    • Multizone Cluster: With a multizone cluster, it is possible to apply hard-to-achieve fault-tolerant architectures where a container running on a zone is automatically moved to another zone if there is a failure. By coupling that with GCP’s ability to replicate volumes across zones and you can deliver a true fault-tolerant architecture.
    • Millisecond recovery: Any restarted container takes milliseconds to get ready again, so absolutely no interruption occurs.
    • Microservice Isolation: Misbehaving containers won’t affect others as there are reinforced limits in terms of CPU and Memory usage.

    Deployment as Code

    GitOps is our mantra. GitOps is a way of implementing continuous deployment for cloud-native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and continuous deployment tools.

    The technique here is to follow regular Git Flow methodology and have automated “operators” apply changes to a Kubernetes cluster. These operators are regular containers running on a Kubernetes cluster, which constantly monitor Git source repositories for changes. Once a change is detected, the operators automatically trigger an update.

    For the automated installations, use Helm as the deployment engine. When changes are committed to the Helm configuration in Git, the operators automatically apply those changes.

    This approach essentially reverts the classical imperative deployment model where actions are performed in the environment to a declarative approach where the state of the environment is defined by a set of rules and kept in sync by these operators.

    Outstanding levels of governance can also be achieved in all clusters from a single source of truth. If a manual change was introduced in any of the environments, the operator would detect and revert back to the defined state.

    Normalize Hybrid Environments

    Kubernetes is powerful, but comes at a price. It is very challenging to maintain different versions and distributions, especially when using different cloud providers and on-premises environments. Due to that fact, you must identify a technology that would abstract the complexity away, normalizing the operation.

    Consider Google Anthos for this, which is a full Kubernetes distribution based on Google Kubernetes Engine and is available to Google Cloud Platform customers. Over the years, Google refined its Kubernetes distribution and eventually released it as a product in its cloud platform.

    Main advantages of using a technology such as Anthos include:

    • Standard Kubernetes installation for on-premises, VMware-based environments.
    • Connectors for Kubernetes Engines in AWS and Azure cloud providers.
    • Built-in configuration management capabilities allowing us to declare our clusters and keep them in-sync.
    • Remote-controlled Kubernetes environments from a single admin portal so all cluster resources are easily accessible.
    • Monitoring metrics consolidated on Google’s StackDriver.

    The three ways are more than enough to achieve greater scalability, governance and control of hybrid environments to address DevOps and complexity. They are actually a new mindset for application design and operations. I truly believe that they can help companies deliver better software while recognizing the complexity and challenges of dealing with enterprise applications.

  • Operationalizing Kubernetes Virtual Summit Speaker Spotlight: James Strachan, Liz Rice, Priyanka Sharma and Tim Hockin

    Operationalizing Kubernetes Virtual Summit Speaker Spotlight: James Strachan, Liz Rice, Priyanka Sharma and Tim Hockin

    The Operationalizing Kubernetes Virtual Summit will bring together Kubernetes and cloud-native community members for a unique learning experience focused on the tools and best practices you need in order to successfully secure and manage Kubernetes. Presented in a virtual reality environment, the event will take place on Oct. 1, at 10 a.m. EDT.

     

    Operationalizing Kubernetes Virtual Summit - keynote speakers - James Strachan, Liz Rice, Priyanka Sharma, Tim Hockin

    The Operationalizing Kubernetes Virtual Summit is a free, interactive virtual conference featuring a stellar lineup of Kubernetes and cloud-native experts, including keynote speakers James Strachan, Liz Rice, Priyanka Sharma and Tim Hockin.

    James Strachan, distinguished engineer at CloudBees, is one of the four brilliant keynote speakers presenting at the virtual event. James is co-founder of Jenkins X, an open source project that helps developers automate their CI/CD processes for cloud native applications. James is also the creator of the Apache Groovy programming language and the Apache Camel integration framework.

    In his keynote session “Using Jenkins, Jenkins X and Tekton with GitOps,” James will demonstrate how Jenkins, Jenkins X and Tekton can solve all of your cloud-native CI/CD requirements using a simple GitOps approach that is easy to set up, use and manage from Git.

    AWS Container Hero, Liz Rice, will also make an appearance at the virtual conference as keynote speaker. Liz is vice president of open source engineering at Aqua Security, where she works on container-related open source projects, and she’s also chair of the CNCF’s Technical Oversight Committee.

    The author of “Container Security: Fundamental Technology Concepts that Protect Containerized Applications” will review what you do and don’t need to worry about when running your cloud native applications during her session, “The State of Kubernetes Security.”

    Another CNCF member joining as keynote speaker is Priyanka Sharma, general manager at CNCF. Priyanka was previously the director of Cloud Native Alliances at GitLab, where she built the developer evangelism team that participates regularly in the cloud native community. Priyanka has contributed to several CNCF projects such as Jaeger and Vitess and was a founding team member of the OpenTracing standard.

    During her talk, “What 6.5 Million Developers Have in Common: Kubernetes,” Priyanka will share some interesting findings from research done by CNCF on the cloud-native ecosystem and will also discuss Kubernetes and cloud-native trends and best practices.

    Last but not least, Tim Hockin, principal software engineer at Google, will be interviewed for the keynote session “Operationalizing Kubernetes: Interview with Tim Hockin.” Tim works on the Google Kubernetes Engine (GKE) and is co-founder of the Kubernetes project. He has also worked on Google’s Borg and Omega projects as well as the Linux Kernel.

    As Kubernetes keeps gaining traction in mainstream IT environments, the next big challenge IT teams will face is operationalizing the platform at scale. But, is the Kubernetes ecosystem mature enough to operationalize at scale? Attend Tim’s keynote session to find out.

    Join this interactive, multi-track virtual conference and learn how thought leaders are embracing containers and microservices environments, leveraging cloud native technologies and enabling digital transformation with Kubernetes.

    You can hear from these keynote speakers and more than 30 other expert speakers at Operationalizing Kubernetes Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Operationalizing Kubernetes Virtual Summit website.

  • Instana Discovers Root Cause of a Microservices Crash

    Instana Discovers Root Cause of a Microservices Crash

    Instana has added an automated process crash and root cause detection capability to its namesake application performance management (APM) platform optimized for microservices.

    Microservices prevent application outages by automatically rerouting application traffic in the event any microservice becomes unavailable. The overall performance of an application will degrade gracefully instead of allowing the entire applications to crash—assuming, of course, there is no single point of failure. However, the performance of the overall application will generally stay suboptimal until the microservice that failed is discovered and updated.

    Chris Farrell, technical director and APM strategist at Instana, said in the absence of an APM platform that can automatically detect when a specific process has crashed, a DevOps team can spend a significant amount of time and effort looking for the root cause. That can be especially frustrating when it turns out the microservice itself only takes a few minutes to repair, he said.

    The Abnormal Process Termination Detection capability is available at no additional charge in the agent software Instana provides for both the software-as-a-service (SaaS) and on-premises editions of its platform. Instana claims it is the first provider of an APM platform to provide this capability.

    Farrell said containers deployed on Kubernetes clusters coupled with serverless computing frameworks based on functions are driving the next wave of cloud-native applications. The inherent complexity of those applications requires a different approach to APM based on real-time analytics and distributed tracing capabilities, he said, adding relying on log data and sampling is no longer sufficient.

    When integrated with a third-party incident management system, it then becomes possible for extended IT teams to proactively resolve many application performance issues before most end users ever notice, he said.

    IT organizations are embracing microservices at scale because they need to build applications faster that are both more flexible and resilient. The challenge they encounter is microservices-based applications can become unwieldy to manage. Dependencies between microservices can create a maze of connections that can be difficult to monitor and maintain. It’s inevitable at some point one or more microservices may become unavailable because of, for example, an application programming interface (API) that has been updated or hardware failure.

    Regardless of the root cause, the sudden loss of a microservice should not result in catastrophic application failure. It can, however, adversely impact the end user experience. Most DevOps teams are committed to resolving such issues before they trigger a set of potential cascading problems that result in time being wasted in “war rooms” to diagnose the root cause of a problem. At a time when most DevOps teams are working remotely, there’s naturally a real incentive to reduce the number of virtual meetings DevOps team members might be called upon to attend. Most IT organizations are already struggling to manage complex IT environments at a time when organizations are trying to limit headcount in the wake of the economic downturn brought on by the COVID-19 pandemic.

    Of course, an APM platform isn’t going to eliminate the need for every meeting. It could, however, make the ones that members of the DevOps do need to attend a lot more pleasant for all concerned.