devopsy.kinsta.cloud

Tag: cloud-native apps

  • Dependencies in Cloud-Native Apps can Amplify Risks

    Dependencies in Cloud-Native Apps can Amplify Risks

    Hidden Dependencies in Cloud-Native Apps can Amplify Security Risks

    Cloud-native applications and modern development practices result in applications that are highly distributed and loosely coupled. In many cases, organizations have no control over or little insight into the different elements and software entities they use in their applications. The result often is hidden dependencies that can impact performance and add to security risks.

    The New York Times noted an example of the consequences of hidden dependencies. The article cited the work of researchers who observed that the quality of weather forecasting models declined as air travel dropped off during the pandemic. One might easily conjecture there was a physical cause and effect. Jet engine exhaust includes water vapor, soot, carbon dioxide, unburned fuel, and several oxides. Perhaps the diminished amounts of these particulates due to fewer commercial flights had some impact on lower stratospheric dynamics.

    It turns out that was not the case. The article reported that researchers found “that when a short-term forecasting model received less data on temperature, wind, and humidity from aircraft, the forecast skill (the difference between predicted meteorological conditions and what actually occurred) was worse.”

    Atmospheric observations made by instruments on commercial and cargo planes are “among the most important data used in forecasting models,” according to the article. The measurements are transmitted in real-time to forecasting organizations around the world, including the National Weather Service.

    The pandemic resulted in fewer flights. So, there was less or no data. A prediction’s degradation due to this data disruption not only impacted the primary forecasting application but had many downstream implications. For example, these short-term forecasts are used by many industries (logistics, agriculture, entertainment, public safety, and more) to make business decisions. Hence, the degradation of performance in that one application due to previously unknown dependencies could propagate to third-party apps that simply relied on the output of this one app as input for theirs. In a sense, this particular dependency (fewer observations leading to poorer quality forecasts) becomes yet a different hidden dependency in many other applications.

    Security implications

    As this example illustrates, small changes in complex systems can have unexpected application performance impacts. They also can impart unintended security problems.

    At the heart of the issue is the fact that today’s cloud-native applications are complex systems. And security in cloud-native systems can be impacted by small changes.

    It might be something as simple as reusing a component whose original permission setting gave a development team broad access to certain data for testing purposes only. With software component reuse being quite common, that point may be forgotten at some point, and the code might be made available to other groups. Those groups may just want anonymized records in that database or a subset of data that did not include records that should remain private. Use of that code in a larger cloud-native app for such purposes would not necessarily expose the data. But someone might discover the mistake later and exploit it.

    Another aspect of cloud-native application security is that many modular elements are linked together via APIs and microservice calls to form a larger application. Those software elements (be they open-source or commercial) often have security flaws.

    A report last year by the Laboratory for Innovation Science at Harvard and The Linux Foundation highlighted this issue, noting the need for an “understanding and addressing of the security complexities in the modern-day software supply chain.” With frequent reuse of components, even if a known vulnerability is taken care of with a patch, the problem may not be eliminated. Someone needs to know that piece of code is in a distributed cloud-native app, that there is a patch for the vulnerability, and that the patch was applied.

    Any small flaws like this can have a larger negative effect on the security of the entire cloud-native system.

    What’s needed

    The reliance on open source and third-party code in cloud-native applications requires that security be entrenched throughout an application’s lifecycle. It is no longer enough to test for vulnerabilities after the fact. Third-party or open-source code used in any one element of a larger application might be changed at any time. If a vulnerability is introduced, a developer might not know of it.

    The inter-dependent nature of discrete code working together in a vast cloud-native app thus requires a new take on security. The constant refreshing, updating, and replacement of applications dictate that security must be an integral part of the entire lifecycle of an application. As such, companies must bring security into the application lifecycle just as DevOps does for development and deployment.

    To find these impacts, stay ahead of them, and react effectively and efficiently when they show up, developers and companies need a deep understanding of the context of their systems and how all the parts work together. Just as the pandemic-related downturn in commercial flights impacted the accuracy of forecasting models, so to can a seemingly unrelated (or unknows) security flaw in one part of a cloud-native application impact the entire application.

    To avoid such problems, a DevSecOps approach is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s applications comprised of many interconnected parts.

  • Survey Shows Mounting DevOps Frustration and Costs

    Survey Shows Mounting DevOps Frustration and Costs

    A survey of 400 developers and DevOps team members in the U.S. and Europe found, on average, 15 hours a week are being spent managing tasks such as debugging pipelines and waiting for tests and builds to complete.

    Conducted by the market research firm Vanson Bourne on behalf of Garden, a provider of a platform for automating application development and deployment tasks in Kubernetes environments, the survey finds more than three-quarters of respondents (76%) said the time spent on these and other manual DevOps tasks is generally being wasted.

    Garden CEO Jon Edvald said, all told, 39% of a 40-hour workweek is typically devoted to these tasks. When the number of developers and DevOps specialists that are employed today are factored into that equation along with their salaries, as much as $61 billion is being wasted on these tasks in the U.S. alone, he noted.

    The top sources of DevOps frustration cited by survey respondents are waiting for pipelines to run (76%), waiting for builds and tests (74%) and setting up, maintaining and debugging pipelines/automation (71%). In fact, only 11% of all respondents are completely happy with their development setups and workflows.

    Those hidden costs may even increase as organizations bring on additional DevOps expertise. A full 83% of respondents said their organizations are planning to hire more staff or increase their use of freelancers/outsourcing into DevOps roles in 2021. Three quarters (75%) said DevOps budgets have increased or will increase compared to 2020.

    In addition, the adoption of more complex platforms, such as Kubernetes, may also conspire to increase costs, noted Edvald. Respondents at organizations not yet using Kubernetes spend an average of 14.3 hours per week on low-level DevOps tasks, as compared to 16.5 hours a week for those who are already using Kubernetes. Nearly two-thirds of respondents (62%) said their organizations are already using Kubernetes, while 31% are currently evaluating it, to varying degrees. A full 95% of respondents using Kubernetes have faced challenges after rolling it out, including training and onboarding (37%) or complexity of setup/configuration (35%).

    Of course, not all the time that might be saved is going to be applied to tasks that increase overall productivity; nearly half of respondents (49%) said if they had it, they would spend more time developing new products and services.

    Specifically, 46% said they would improve speed and delivery of existing products and services, while 44% said they would focus on improving security for existing products and services.

    Edvald said the survey makes it clear there’s still plenty of opportunity to automate repetitive DevOps tasks. Organizations are spending too much time on the care and feeding of DevOps platforms that takes time away from building and deploying applications, noted Edvald.

    Less clear is when organizations will reach some type of DevOps breaking point. Garden is betting that the transition to cloud-native applications based on microservices will eventually force the DevOps automation issue. However, in organizations that only know the DevOps processes they have used for years, change may be a long time in coming.

  • What It Really Takes to Build a Reliable App

    What It Really Takes to Build a Reliable App

    What makes an app reliable? If you ask most IT professionals that question, their minds immediately go to uptime. That’s not surprising; after all, it’s fashionable for software and infrastructure vendors these days to boast about how many nines of uptime they guarantee.

    To be sure, uptime is one component of delivering a reliable application experience for developers and end-users. But it’s only one. In order to build reliability into your application patterns, you must think beyond uptime alone.

    Keep reading for an overview of all the factors that go into achieving reliability.

    What Is Reliability?

    A reliable application is one that meets the needs and expectations of everyone it serves. While those needs and expectations will vary from case to case, reliability is characterized by the ability of an app to:

    • Be accessible when needed.
    • Respond within the time frame needed.
    • Be updated or modified as needed.
    • Provide security and privacy to the extent needed.
    • Meet the needs and expectations not just of end-users, but of everyone else who helps create or support the app.

    Maximizing Reliability for Cloud-Native Apps

    Achieving these features for modern, cloud-native applications requires a multi-pronged approach. The following are the core considerations to address in order to build reliability into an app pattern:

    Uptime

    We’ll start with uptime, which is the most obvious aspect of reliability. Uptime refers to the amount of time that your application is available, at least to some extent (as we’ll discuss below, merely being available does not necessarily mean that the app satisfies other requirements of reliability).

    Maximizing uptime typically involves solutions such as distributing workloads across different servers or data centers (so if part of your infrastructure fails, others remain available) and using automated failover to move a workload to new infrastructure if it fails in one location.

    Culture and processes are part of the picture, too, since you need to make sure your team is prepared to respond quickly to any incidents that arise, in order to minimize downtime.

    It’s worth noting, by the way, there can be such a thing as too much uptime. If you reach the point where adding more uptime doesn’t deliver any additional value to your organization, then it’s probably time to stop. Adding another nine to your availability, just because you can, might be a poor use of resources. So, be sure to factor this part of the equation into your uptime calculations and strategy.

    Performance and Efficiency

    In order to meet stakeholder needs and expectations, an application must not only be available, but also able to respond within the time frame required by those stakeholders. A website that is up 100% of the time but takes 20 seconds to load each page is not a very reliable website.

    This is why performance testing and monitoring must be built into your application delivery chain. You should also ensure that you rightsize infrastructure (for example, by choosing the right types of cloud instances) in order to guarantee that your applications have enough resources available to perform adequately. (Of course, this priority must be balanced with cost-control.)

    Accessibility and Usability

    An application that is available all of the time and responds quickly may still fail to meet stakeholder needs if it is difficult to work with due to poor design.

    From an end-user’s perspective, user-experience testing is the most obvious way to help mitigate the risk of poor accessibility or usability within your applications. But keep in mind that you also need to think about usability from the perspective of your own team. Make sure that access-control systems, infrastructure architectures and documentation can be navigated easily. You don’t want an application or a delivery chain that is too complex for your team to be able to support effectively.

    Security and Data Privacy

    A reliable application is a secure application. There are many obvious ways to help secure applications, such as using vulnerability monitoring tools. But remember security is not just about finding vulnerabilities as they arise or deploying certain tools. You must also build security into the design of your infrastructure, processes and culture.

    Backup and Recovery

    You don’t need to be a seasoned IT professional to know that backing up data is important for achieving reliability. When something goes wrong–which it occasionally will, despite your best plans and efforts–having a backup in place often means the difference between experiencing a blip in service and a major catastrophe.

    The thing that can be easier to overlook is the importance of having a disaster recovery plan in place as well as a backup routine. Simply backing up your data isn’t enough; you must also know how you’re going to restore it to new application instances quickly if disaster strikes. If, for example, all of your cloud-based virtual machines go down, what is the exact process you’ll follow for standing them back up? Identifying the steps ahead of time–and, ideally, scripting them so the recovery process can be as automated as possible–is crucial.

    Also important is quantifying how often you need to back up data, which is determined by a metric called Recovery Point Objective (RPO), and how quickly you need to be able to recover it to avoid serious business disruption–determined by Recovery Time Objective (RTO). Along similar lines, error budgets, which define how much time you can tolerate your production systems being down, can help you define the available time monthly for making system improvements.

    Modifiability

    Few apps are deployed and then never modified again. Instead, they must be updated or scaled constantly to meet changing needs and demands. That’s why designing an application pattern that can be easily modified is critical for achieving reliability over the long term.

    In practice, modifiability entails having the right tools (such as automated deployment solutions) and the right processes (such as clear feedback loops between ITOps and developers) in order to decide efficiently what modifications to implement. It might also involve taking advantage of infrastructure technologies (such as containers) that make it easy to update a running application without imposing downtime on users.

    Conclusion

    Reliability is more complex than it may seem. No matter how many nines are included in your SLAs, you are not guaranteeing true reliability unless you also address requirements such as performance, usability and modifiability.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • DevOps Chats: Database for Cloud-Native Apps with MemSQL

    DevOps Chats: Database for Cloud-Native Apps with MemSQL

    Data and database technologies are experiencing disruption. The volume of data collected is exploding, creating new potential for disruptive services and new companies. Data is distributed across locations in the cloud and the data center. Also, cloud technologies bring a plethora of database types, distribution options, analytics capabilities and AI/ML processing. Any company not leveraging data to the benefit of its customers and business are just asking to be the next victim of disruption.

    Nikita Shamgunov, MemSQL co-CEO/co-founder, joins DevOps Chat to discuss how these disruptive factors changed how containerized and cloud-native applications approach data collection and storage. Speed, high volume data collection, distributed design and scale are all challenges Nikita sees as vital for cloud-native applications of today and the future.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Nikita Shamgunov, co-CEO and co-founder of MemSQL. The topic today is really looking at the state of database and the market and technology as we think about database now. Nikita, welcome to DevOps Chat.

    Nikita Shamgunov: Thank you, thank you—excited to be here.

    Ashley: It’s a pleasure to have you on. Thanks for joining us. Would you start by introducing yourself, tell us a little bit about what you do and a little bit about MemSQL?

    Shamgunov: Absolutely. My name is Nikita Shamgunov, I’m the co-CEO and co-founder of a database company, MemSQL. Prior to MemSQL, I worked at Facebook, and prior to that at Microsoft on the SQL server kernel. So, I’m a kernel engineer by training. And before that, I graduated with the Ph.D. program from St. Petersburg, Russia.

    Ashley: Excellent, excellent. Well, let’s jump right into it. We were talking a little bit before we started the podcast recording. You know, databases have been around for a long time, and you know, the technologies created decades ago are still in production in many areas, but there’s a lot of changes that are happening, too. Why don’t you talk a little bit about some of the market forces that are happening to change the database environment?

    Shamgunov: Absolutely. So, there’s several market forces and industry forces that are, I would say, piercing through the market and technology. And the first one is that the data volumes are growing, right?

    Ashley: Mm-hmm.

    Shamgunov: And a lot of companies—and you don’t have to go far for examples, you know, companies like Uber and Netflix and Amazon and Google drive most of their value from data, right? That somebody in the ’80s would describe any of those companies as a glorified database application—but, of course, they are a lot more than just that.

    And with the data volumes and variety of that data growing, what separates winners from losers is how well people can capture and act on data.

    Ashley: Mm-hmm.

    Shamgunov: Right? A great example is, you know, when you’re hailing an Uber, you know, you pop it in your phone and then you know exactly where the cars are, how fast they’re gonna arrive, how long it’s gonna take you to the destination.

    And that’s really, really powerful. We’re all used to this right now, but 10 years ago, that was not a reality and not a possibility. So, that is the force number one, right? People see who are those companies that are advancing in the market and they wanna take on the same opportunity in their state, in their category.

    They also are afraid of being disrupted by the next Uber, the next Facebook, the next Amazon—particularly Amazon.

    Ashley: Exactly.

    Shamgunov: So, the second market force that is going through the market is architectural. And, because the data volumes are growing and the Moore’s Law is not working any more, so we cannot just rely on better, cheaper hardware, we have to build distributed systems.

    And, in the database world, distributed systems, for the most part, have been exotic until quite recently. And we’re starting to see distributed database systems—and the reality is, it’s just very hard to build a distributed kinda system of record transactional system and make it production ready, because the amount of technology that goes in there is enormous, and different, kinda other database products that are successful in the market have been products for 30 plus years. You know, thinking about Oracle, thinking about SQL Server.

    Ashley: Mm-hmm.

    Shamgunov: And when this massive architectural change comes in where it’s a business reality that you need to re-architect those systems, then it becomes very, very hard for the vendors to actually deliver those. So, that’s the second market force. Transition [Crosstalk]—

    Ashley: Let me ask you a little bit about that, Nikita, if I could, about the—

    Shamgunov: —towards distributed systems—go ahead.

    Ashley: The distributed architectures, do you see that happening largely because of the displacement between on-prem data centers and private clouds and public clouds? Is it more pushing content to the edge and doing caching? Is it pushing content toward a geographical location? What’s forcing the distribution of databases?

    Shamgunov: This is a wonderful question, first and foremost, because I was about to say that the third mega market force that is happening right now is moved to the cloud.

    Ashley: Mm-hmm.

    Shamgunov: Right, and cloud, if you make it parallel with electricity, right, the majority of the world consumes electricity in the clouds, you know? You just plug your stuff into a socket and here comes your electricity.

    Ashley: Mm-hmm.

    Shamgunov: On premises, generators still exist at important places—manufacturing, health care, hospitals—but it’s a tiny percentage of the global electricity consumption.

    Similarly, it just makes too much sense to consume IT in the cloud, and within IT, you know, there’s applications, analytics, databases, machine learning—you know, all the whole spectrum of services that typically a cloud provider now offers. Now, if we buy into this worldview—and certainly, we see what happened with electricity, and this is the same thing that’s happening in IT—then you can split the same into different workloads. And once you zoom in on the database workloads, you will realize that, yes, you wanna take workloads that currently run in data centers and shift them into the cloud.

    Cloud is different, you know? The most important thing in the cloud is that software just runs as a service. But also, it creates an opportunity to rebuild every single piece of IT for the cloud. And that’s already happening. In our space, it’s already happened in data warehousing, but it also happened with identity because of Okta. It happened with cloud storage, with services like S3 on Amazon or Dropbox as a higher level service. So, basically, as infrastructure IT is shifting towards the cloud, we are rebuilding it for the cloud. And now, it just so happens that, through that rebuild, you want to cater to the next generation workloads. That’s where distributed systems comes in. And also, you’re architecting for the cloud because the cost equation in the cloud is different.

    So, being scalable and elastic allows you to provide a better cost equation, as opposed to legacy architectures. So, if you take an Oracle and—yeah, you can run it in the cloud, in EDM, no problem. Well, actually, it’s gonna be way too slow and way too expensive as opposed to the system that’s architected specifically for the cloud that scales both for cost, right, so you can only—you will only consume as many resources as you need from the storage and compute standpoint. Storage compute network bandwidth—whatever you need to run the workload. But it also is gonna be a lot more efficient, because running a database as EDM, everybody will tell you this is not such a great idea, but if it’s a database service architected for the cloud, then you can build for and around—around limitations and for all the services and resources that are available for the cloud.

    Ashley: What I’d like to ask you about that is, it seems like there’s a parallel between lift and shift for applications and lift and shift for database. It isn’t architected for the cloud if you’re just taking the application into a cloud environment, but you’ve gotta re-architect, rebuild, take advantage of things like database as a service, for example. Is that correct?

    Shamgunov: Absolutely. Alright, and then in the application space, what’s different than the cloud is that certain applications can be more popular than others. And if you just put those apps as you had on premises in VMs—so, very likely, you both overprovision and underprovision resources.

    For less popular applications you are wasting the whole VM to run an app, and for a very popular application you don’t have enough network bandwidth or CPU to run this app at scale. And that’s why Kubernetes really changed the game, and if you build against Kubernetes, you can pre-release scaled, stateless applications. And then, if you run it in the cloud, of course, the database that you use to power those applications, you consume as a service.

    Ashley: Say a little bit more about that, because we’ve talked on other webinars and podcasts about the statefulness of data versus the more dynamic nature of building software and rebuilding software that may not match up with the state of the database. How do you handle that in a Kubernetes environment?

    Shamgunov: So, there are two pieces to this. The first one is, you run your application in the Kubernetes environment and you consume data through a database as a service. So, that is a blueprint of a cloud architecture today. Let’s say you run your Kubernetes on Amazon, your application is written in whatever language, but let’s say Node.js, and you fire up DynamoDB, using an Amazon example, as a service, you connect to that database from the application and there it is, there’s your app.

    Now, in the world of relational databases—which, by the way, is a much larger slice of the market than object databases—

    Ashley: Sure, yeah.

    Shamgunov: And for a very good reason. You can run it in a similar fashion. You know, in this case, you can launch MemSQL as a service, you know, run  your application inside a Kubernetes cluster.

    The other thing that you can do is, you can bring MemSQL with you into the Kubernetes environment. And that gives you control and cloud portability. Now, not only do you deploy your application into Kubernetes and the application scales depending on the demands and the popularity of the app, but also the database that stores the data and powers the app can be deployed in the same Kubernetes cluster, and it will do the same thing. It will scale or contract, depending on the needs of your application.

    So, what it gives you, it gives you cloud portability. So, you can pack your bags and go from AWS to Google, for example, and the other thing it allows you to do is to take it and bring it down, right, from cloud to on premises. And today, the reason to do so is usually twofold. It’s either security and compliance or it’s cost, right? If the workloads are pretty static and you cannot drive a good amount of efficiency through the elasticity of your both application and data infrastructure, then on premises may still be cheaper, and then that creates an incentive for you to bring it down on the ground.

    Ashley: How important is it to have kind of a single tool to do ETL versus separating those as you move not only within one cloud but across clouds?

    Shamgunov: Well, I think, at the end of the day, we are talking about lock in, and we’re talking about developer productivity. Those are completely different. Now, lock in is something that a lot of people in our space experience with Oracle as a vendor.

    Ashley: Sure.

    Shamgunov: Where they go through what they describe as extortion cycles. Every time an Oracle renewal comes in, then you end up negotiating with Oracle, and if you wanna reduce the amount of the database spent, it becomes a very difficult conversation. You know, Oracle runs an audit, which they have the right to, so they inspect and find all the applications that consume Oracle. If you reduce the amount of consumption, Oracle jacks up the maintenance fee or jacks up the next license fee.

    So, it’s really, really hard to get out of spending a lot of money on this vendor. We hear that time and time again in major, major enterprises. I had a conversation with the CIO of a major bank, and the Oracle spend there is $1 billion over several years.

    Ashley: Not surprising, yeah.

    Shamgunov: And this is absolutely insane, if you think about it, right? The reason for that is that Oracle has been a great partner for delivering their services, you know, cost aside. You know, banking runs—in their bank, it’s a consumer bank, and it runs on Oracle.

    But at the same time, competitors catch up to the functionality, right? MemSQL comes with a very strong system of record capabilities and, to this day, that has been the stronghold of Oracle, and you know, with a much  more attractive price, with a much more flexible deployment model and the ability to run in the cloud as a database as a service where we guarantee SLAs enough time. And with an integration with AI and ML, we see that, slowly but surely, that equation is shifting. And, you know, people seriously ask questions, “Why would we spend so much money on this technology and can we not do this? We would save hundreds and hundreds of millions of dollars and drive shareholder value, here. In addition to that, we’ll have our development teams move a lot faster,” right?

    So, back to your question about across clouds and developer productivity, right? The first one is lock in, and I gave you an example of an Oracle lock in. But now, the CIOs don’t want to fall into the same trap by getting married to a single cloud provider. And, you know, thank God, we have multiple cloud providers available on the market, of which three in the United States are very, very strong, and you know, for the most part, similar in capabilities—GTP, Azure, and AWS.

    So, it’s very typical for a key enterprise to choose two or three cloud vendors. So, that prevents the lock in. However, in order to truly avoid lock in, you’ve gotta choose service providers that allow to run their software the same way on all the clouds.

    Ashley: Exactly.

    Shamgunov: And ideally, they deliver their services as a path service, you know, like a database as a service, and that service is available on every cloud. And if that’s the case, then, you know, you take a dependency on a vendor, but you are not taking a dependency on the mega vendor, which is one of the clouds. So, that is something that is top of mind of every CIO that I know.

    Ashley: You make a good point about Oracle, kinda going back to the lock in of the 2000s and maybe ‘90s. You know, for VLDB, that was really the best game in town, arguably. You could also Microsoft, maybe.

    Shamgunov: Mm-hmm.

    Ashley: But that isn’t true today. You’ve got many options when you go to cloud providers and folks like yourselves, I would imagine, live in all of those cloud environments or multiple of them. So, you can also serve customers that, of course, are gonna have a multi-cloud strategy.

    Shamgunov: Absolutely, you know, I couldn’t have said it better.

    Ashley: Okay, great. [Laughter] Lock that one in—great. What’s the number one challenge as folks move out of—let’s pick Oracle again—move out of that traditional VLDB environment and move into the cloud. What’s the paradigm shift that you have to make to really think about how you can leverage the flexibility of the cloud?

    Shamgunov: There is a three step strategy if you wanna get out of Oracle. The biggest stickiness of any database technology is all the applications that are built against the database and they’re using and sharing that data across the applications. And then different database technologies can either be app compatible—you know, an example of that is MySQL and AWS Aurora, right?

    Ashley: Mm-hmm.

    Shamgunov: Aurora is a new database, but the compute piece of it is actually MySQL code, so they’re app compatible. If an app works against MySQL, it’s gonna work against Aurora.

    So, that’s why, in the low end of the market, in which both MySQL and Aurora play, this can be a viable strategy. And it’s a very good one, right, because it’s so easy to just point your app at a different database. And it’s very hard for a different database product to achieve application level compatibility between the two databases.

    The second one is workload compatibility. So, all our workloads that are running on Oracle can be moved to another database, assuming there is a good enough reason. You know, assuming the database you’re moving the workload to has all the same set of features and provides strong system of record guarantees and so on and so forth.

    So, if you are workload compatible, then you can move from one database into another, but you need to put in some work, right? You need to augment and potentially rewrite certain pieces of the application.

    Ashley: Mm-hmm.

    Shamgunov: And, in our space, there’s a massive piece of the market that is called tier one workloads. Those tier one workloads typically run on Oracle, and they have either very, very strong system of record requirements or they have performance requirements, or they have availability requirements, or they have very strong concurrency requirements.

    And because of our architecture, we are practically the only game in town that can be the destination for moving workloads from Oracle, and especially systems like Oracle—you know, heavy Oracle systems running on enterprise storage or systems like Oracle Rack or Oracle Exadata over to running on MemSQL. And we have countless examples of how we quote-unquote liberated our customers from Oracle.

    So—and this is, frankly, our biggest opportunity. So you will have to put some work, but if the pain that you’re experiencing is so high that you’re willing to put that work, we are a fantastic destination for moving your Oracle workloads.

    Ashley: Well, excellent. You’ve been a great guest and a fascinating conversation. I wish we had more time to chat more. Maybe we can do that on another podcast.

    Well, thank you, and with my audience, I’d also like to thank you, Nikita Shamgunov, for joining us, co-CEO and co-founder of MemSQL.

    Shamgunov: Yeah, very happy to be here. Thank you so much.

    Ashley: You bet. And thank you to our listeners. This is Mitch Ashley with devopsy.kinsta.cloud and you’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • What Are AWS Application Patterns?

    What Are AWS Application Patterns?

    The cloud-native approach is not just about compute power and cloud services. A “set it and forget it” attitude won’t work with cloud native; there are far too many moving pieces and there is just way too much complexity. Instead, this approach requires constant testing, optimization and improvement. This is epitomized in the two key phrases of the DevOps methodology: continuous integration and continuous delivery.

    To make this a reality, however, it takes a strategic approach to defining application patterns that will govern the way in which cloud-native applications are built and shipped, rather than a one-off effort. Since AWS is the leading cloud provider, we should discuss which application patterns are relevant to the AWS platform. There are many aspects to consider when it comes to AWS application patterns, and we will cover them here.

    Operational Excellence

    The best starting point for application patterns is a commitment to operational excellence. Typically, the term “Ops” is used to identify the IT team, but in this case, operational excellence rests on the shoulders of Dev, QA and Ops teams. In cross-functional DevOps teams, every member should strive for operational excellence at every step–even in the smallest of tasks.

    In their white paper on operational excellence, AWS encourages its users to manage operations as code. This helps avoid human error, enables automation of complex processes and allows for quick and easy rollback when errors occur. Failure, according to AWS, is an opportunity for learning. They even advise performing “pre-mortems” that try to anticipate potential points of failure before a deployment.

    AWS Trusted Advisor is a useful tool that enables this type of accountability and shared responsibility within a team. It checks and reviews your new and existing AWS workloads looking for opportunities to save costs, improve performance, tighten security or follow best practices for scaling operations.

    Security

    Security is a pattern that is non-negotiable. The term “DevOps” has inspired another variation called DevSecOps that signifies this fact. Security operations take center stage when talking about DevOps.

    The interesting thing about DevSecOps is it actually results in more freedom, flexibility and trust across teams when done right. This is unlike traditional approaches to security which created silos, stifled creativity and slowed down innovation. Security is now a key piece of the puzzle, not an afterthought. AWS has many machine learning-based security solutions such as Macie which automatically identifies and secures personally identifiable information (PII).

    Along with this, configuring role-based access controls using AWS IAM is essential to have greater control over who or which applications access data and for how long. Access Control Lists govern access to data stored in AWS S3 buckets.

    The news is full of instances of data breaches due to weak security policies and access controls. Capital One is a recent example of a data breach that affected 100 million of its users. While security in the cloud is more complex than before, AWS has the necessary tools and systems in place. It’s up to organizations to implement a security strategy that prevents misuse of their data.

    Reliability

    Today, there is a low tolerance for downtime because of the potential loss of revenue. With the stakes so high, reliability is a pattern any application custodian would have high on their list of priorities. AWS has multiple reporting and health monitoring tools to keep you constantly on the pulse of your applications.

    Architectural patterns like microservices enable better resilience by decomposing monolithic applications into more manageable chunks called services. This “divide and conquer” approach leads to higher availability, which is critical for SaaS applications.

    Patterns like chaos engineering seek to intentionally kill random instances and services and force the DevOps team to figure out workarounds and backups for every scenario.

    Application Performance

    With the explosion of data, applications are always dealing with lots of data to transfer, store and process. An application’s performance depends on three factors: the backend data storage layer, the middleware components and the frontend.

    The backend data layer is the most critical component when it comes to performance. Choosing the right storage formats, database types, storage devices and organization patterns all contribute to the speed of data access. AWS has an amazing array of storage services, including S3, RedShift, Aurora and Glacier. AWS gives its users every type of storage solution, all of which should be considered to improve data management.

    AWS is devising new ways to query large datasets without bearing the load on your existing systems. RedShift Spectrum is one example of this. It is a great way to “minimize the need to scale Redshift with a new node, which can be expensive.” If you’d still rather not have to manage any RedShift clusters on your own AWS Athena is a great serverless alternative

    That gives you all the power you need to query large datasets in S3 without having to maintain any clusters of your own.

    This pay-per-use model is making its ways across the entire AWS stack with services such as ECS and Fargate offering completely serverless experiences when operating containers at scale. What started out with AWS Lambda is catching on fast, and many AWS services like the ones mentioned above enable serverless experiences with a focus on application performance.

    Cost Optimization

    When moving to the cloud, pricing is completely different. Rather than paying for perpetual licenses, you now pay a small fee for every small resource that you use. Though small on its own, you’ll soon realize that cloud costs can shoot up easily if you’re not paying close attention to your spending.

    Cost optimization is necessary as you scale operations in the cloud. Cost optimization includes looking for more efficient services, whether that’s within the same vendor platform or a different platform. At a minimum it may require a lift-and-shift approach to transition from expensive old infrastructure to inexpensive new alternatives. For example, shifting workloads from VMs to containers to serverless within the same platform can show great cost savings, since containers and serverless are generally more cost-effective than VMs.

    It pays to leverage the expertise of experts in this area. They should ideally be people who have spent years using AWS, understand Well-Architected best practices and have found ways to cut costs and derive more value from the same budget.

    Application Patterns Enable Extensibility

    Microservice applications adopt a pluggable architecture. This enables them to be easily integrated with external applications. Typically, API-based communication patterns are most common. AWS API Gateway is a service that manages API design for AWS applications. In some cases, an SDK is the better choice–for example, when you need more control over the developer experience and integrations. It’s important to know when to choose either option.

    Application Patterns Enable Portability

    Portability is the ability to move workloads across instances without interrupting their functioning. As instances change, the workloads which they support shouldn’t be affected. This is only possible if there is a clear separation layer between the workloads and the infrastructure that runs them.

    Application Patterns Enable Shift-Left

    The DevOps methodology is known to encourage a shift-left approach to software delivery. This means that not only Dev, but also QA and Ops contribute to the design and development stage of an application. This fosters deeper collaboration across teams and breaks down silos.

    A shift-right approach holds true as well. Shift-right means developers are responsible for the code they write. They are equal owners with operations teams for the resilience of the apps they build and also the bugs they introduce into the system. This practice of putting ownership and responsibility where it belongs is very healthy for a DevOps team.

    AWS facilitates pipeline management using tools such as CodePipeline, CodeCommit and CodeDeploy. They each perform similar but complementary roles and help build a CI/CD pipeline. They make it easy to get started with CI/CD within the AWS platform.

    For organizations further down the line in their cloud journey, AWS’ pipeline management tools may seem too simplistic for something like GitOps. Instead, they’d want to look outside AWS for tools such as Jenkins X or Weave Flux which are designed with GitOps automation in mind. Whether it’s the simple or advanced route, a pipeline brings great benefits over a manual development process.

    Conclusion

    Though tools enable the implementation of helpful application patterns, on their own, they are ineffective. Application patterns need a deliberate strategy and an approach for a start. Only after a strategy is in place, can you move to deciding which tools to use. With a strong strategy in place, any of the tools mentioned here can be swapped out for other better tools and the results will be the same. It’s important to not be distracted by the next shiny tool but keep a keen focus on the strategy for implementing AWS application patterns.

    As we’ve seen here, application patterns are diverse, but they all build upon each other. Without even one of these pillars, organizations would not be able to realize the goal of cloud-native applications. On the other hand, if they give careful thought to each of these application patterns, organizations would deliver cutting-edge applications that can only get better with the passing of time.

    This sponsored article was written on behalf of Eplexity.

    — Twain Taylor

  • DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    More than ever, application security is a top priority. Beyond secure coding practices, a holistic app security strategy addresses the full application and infrastructure stack. This includes containers, microservices, orchestration, infrastructure software and the cloud. Bolting on the next security tool may not be the answer.

    Kamal Shah, StackRox CEO, joins us on this DevOps Chat, diving into the need for a systemic security approach across the life cycle of cloud-native, even “Kubenative,” applications. We explore how Kubernetes and cloud-native apps bring access to rich configuration information, usage visibility, runtime context, inherent security controls and compliance. It’s a fascinating conversation that will open up new paths to secure Kubernetes and cloud-native applications.

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

    Transcript

    Mitch Ashley: Hi, this is Mitch Ashley from devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Kamal Shah, who’s CEO of StackRox. Our topic today is security in a cloud-native world. Kamal, welcome to DevOps Chat.

    Kamal Shah: It’s great to be here, Mitch. Thank you for having me.

    Ashley: Well, I really appreciate you taking time out of your schedule. I know you’re very busy. Happy to have you on. Would you start by introducing yourself? Tell us a little bit about you and what you do. Of course as CEO we can imagine, but also a little bit about StackRox.

    Shah: Absolutely. So again, I’m Kamal Shah. I’m the CEO of StackRox, and StackRox is a leading provider of security and compliance solutions for your cloud-native infrastructure. So as you’re embarking on your journey towards microservices, containers and Kubernetes, we help you address your security and compliance requirements across the entire application life cycle from build to deploy to runtime.

    Ashley: It’s about secure software, especially in a cloud-native containerized world. That’s for sure. Well, tell us a little bit about how you approach this problem? You know, how do you think about security in a kind of contemporary app development world where you’re doing cloud-native applications? Kub-native, I know is a way that we like to talk about it. How do you approach this from a StackRox standpoint?

    Shah: Absolutely. And so the big trend that we saw when we started the company was that customers were, you know, shifting their monolithic applications built on traditional infrastructure to microservices and containers and as a result security also had to evolve to meet and secure this cloud-native infrastructure. And we saw an opportunity to build a new set of solutions that are purpose built for this cloud-native infrastructure, because when you really think about it there’s fundamental differences between traditional application and traditional security and cloud-native applications and cloud-native security, right? I mean you’re deploying containers; security then has to make sure that it understands the ephemeral and immutable nature of containers and security has to shift left and provide controls and guardrails for the build and deploy side of the application life cycle, not just at run time.

    And equally important, security now has to seamlessly integrate with DevOps processes, automation and workflow, because if you don’t then the DevOps organ is gonna reject—or sorry, the DevOps body is gonna reject the security organ.

    Ashley: [Laughs] I’m glad you talked about it in both ways because Kubernetes, containers, that obviously changed the architecture of software and how we’re doing that in the cloud. You know, it isn’t just about locking down servers anymore. It’s really app security level, but at the same time we’re creating software differently. Can you say some more about what maybe some of the unique challenges are that you’ve had to address for both cloud-native world and also shift left within DevOps?

    Shah: Yeah, absolutely. I mean the one big trend, people talk a lot about microservices and containers, but the other big thing that I would like to call out is that Kubernetes has emerged as the de facto standard for orchestrators, right? We did a survey late last year and again six months later and what we found is the adoption of Kubernetes as the orchestrator has grown from 57 percent of organizations using it to now, you know, over 86 percent of organizations using Kubernetes, right?

    Ashley: Wow.

    Shah: And for the right reasons, because it is really, really hard to scale, manage, and deploy containers in large environments, and Kubernetes was purpose built to help you do that. It was an opensource system developed by Google, and Google today uses Kubernetes or a version of Kubernetes, the internal version, to manage over 4 billion deployments at 4 billion containers at scale. So the first thing here is that you have to appreciate the importance of Kubernetes and you have to make sure that security is focused on not just the container but also at the orchestrator and specifically Kubernetes, right?

    Ashley: Sure.

    Shah: And that itself brings a whole new set of challenges because Kubernetes is a large system with significant operational complexity, right? And they just went through a security audit and the assessment team found that the configuration and deployment of Kubernetes is nontrivial, and I can get into the details as to what those challenges are, but the starting point is to make sure that you’re not just focusing on security at the container layer but also focusing at the Kubernetes layer.

    Ashley: Well, isn’t that the truth. We find so often even outside of the container world it’s oftentimes configuration issues, not just the software itself. And as you mentioned, Kubernetes, well as great as it is, it is very complex to set up and operate. It’s not a simple task. Maybe it is as a developer to get an environment running but not in a multi-cluster distributed environment in the cloud, et cetera, high bred, all that kind of thing.

    Shah: They highlighted, you know, the three reasons why it is nontrivial. The first reason was that there are certain missing operational controls, right? So you obviously have to make sure that you understand what those are and put guardrails in place for those controls. The second is that there are a lot of components that have ability to put controls in place but the default settings are confusing, and the big takeaway for me is that we need to distinguish between security controls being available by default and that doesn’t mean that they are configured securely by default, right? So the misconfiguration is therefore the number one concern that users have and it was expressed by two-thirds of the audience in the StackRox State of Container Security Report that two-thirds of the respondents were concerned about misconfigurations.

    Ashley: I believe you even have that report or some information about that on your website. I remember downloading some of that. It has some great information in it. Talk to us about then how do you approach that from a StackRox product standpoint? What parts of those issues does StackRox come in and really help you solve?

    Shah: Yeah. So, you know, what we have taken is really a holistic approach to container and Kubernetes security and we have focused on making sure that our approach is both container-native and Kubernetes-native. So what does that mean? It means two distinct things. First is making sure that we capture all the rich configuration data that is in Kubernetes and use that to address and improve the efficiency of all the use cases that we address in the product. So let’s take vulnerability management as a very simple use case, right? You can go scan images and say here are a list of all the images with a vulnerability score of seven or higher.

    Now imagine you have hundreds of images with vulnerabilities and you give them to developers. What are they gonna do? And I say, well, they’re gonna throw their hands up in the air and say, “Well, I can’t get to all of them,” and that’s where we had the Equifax problem. But by deeply integrating with Kubernetes and being Kubernetes-native, what StackRox does is takes the additional step of saying, “Hey, you know, it’s great that we have these images with vulnerabilities, that’s a good, important first step, but let’s take the second and third and fourth step to understand are those images even deployed anywhere in your production environment?”

    Ashley: Exactly.

    Shah: Right? And if they’re employed in production environment, what data is it accessing, what secret is it accessing, what’s the network configuration, is it publicly accessible, what behavior are we seeing at runtime? And by taking all this rich context we can t hen give you a prioritized list of risks in your environment so you can focus on the most important risks first as opposed to getting a laundry list of issues. So that’s an important—you know, that’s how Kubernetes-native solutions can help you prioritize risk and that’s precisely what we do at StackRox.

    Ashley: I was just going to say, I think this is an extremely valuable aspect of your product because so many security teams—and I’ve talked to even, you know, major online tech companies that say, “I don’t need more information; I need problems solved, right? Tell me what are the biggest, most important things to go after,” and I think that’s a huge part of what StackRox does.

    Shah: Exactly. And, you know, alert fatigue, as I’m sure you’ve heard, is a very common problem in the security industry.

    Ashley: That’s the nice way to say it. [Laughs]

    Shah: Yeah. And by leverage the context, the rich context available in Kubernetes, you can actually make that information more actionable for your development teams and your security teams. So that’s one example. The other example of what it means to be Kubernetes-native is really to leverage the built-in controls available in Kubernetes for policy enforcement, right? And so let’s take network segmentation as another use case where you want to segment your networks between—inside—so that not every container can talk to every container, and there are two approaches. You know, Kubernetes has something called Network Policies and you can leverage those, and it’s much more scalable and robust and it seamlessly deploys within your infrastructure, right?

    The other approach would be to go deploy a proprietary firewall, which is fraught with scale challenges and creates issues if it fails, right? And so a customer again says, “Hey look, when I’m talking about being Kubernetes-native I want to leverage Kubernetes for what it’s designed to do, leverage the native capabilities, because it’s much more scalable and robust, and I want to make sure that my controls are all in Kubernetes, have a central place for policy enforcement as opposed to multiple proprietary tools doing policy enforcement,” which is not the approach and not what Kubernetes recommends and that’s precisely why they have those built-in controls. And so that’s again another example of what—you know, the advantages of being Kubernetes-native and it allows for native enforcement of your policies.

    Ashley: Well, I think that’s another place where, you know, the DevOps intersects with other parts of the organization, DevSecOps, et cetera. You know, a security team might be used to locking down a server or at a massive application level, and as you’ve mentioned sort of outside of the Kubernetes environment locking something down at the firewall, that doesn’t deal with really what’s happening amongst all the clusters, all the containers, microservices. So you’ve really highlighted an important aspect of security, that once security teams get engaged and find out what’s possible now they can, you know, do that through StackRox. That’s gotta be a huge advantage.

    Shah: Yeah, and precisely the reason why we took this approach, because when we go talk to customers what we find is that there are security teams that care about the controls that we are talking about here and then there are platform and infrastructure teams that are responsible for the operationalization of these tools, right? They are responsible for SLAs. The SREs are the ones that have to operate these container and Kubernetes-native security solutions and, you know, they just prefer solutions that are more native to the infrastructure versus deploying proprietary third party tools. And so having a Kub-native approach also helps align security and DevOps teams, and what we are seeing now is as a result that this emergence of DevSecOps, which is all about bringing the two together and really being responsible for the security of your application and your cloud-native infrastructure.

    Ashley: I’m curious. Who is it usually that’s reaching out to you or showing interest in StackRox? Is it the developers, DevOps folks, is it security folks kind of figuring out how to talk to the dev teams? What do you see happening in the market?

    Shah: Yeah, and a great question. We typically see security teams or security architects or application architects reach out because they know they have to address it, and so that’s where the initial conversation starts. What we find is that when they involve the DevOps teams, because they have to get involved to do a proof of concept or even to deploy an operationalized solution, the DevOps teams actually much prefer a container and Kubernetes-native approach as opposed to a proprietary third party security tool because they often refer to proprietary tools as a root kit that they do not want to install in their infrastructure, right? And so it is—you have to speak to both audiences.

    You have to make sure that you cover all the use cases that security teams care about and you also have to make sure that from a day-to-day operationalization of the product it aligns with your DevOps teams, their processes, their workflows.

    Ashley: I have to believe that’s gotta be a big plus to the security team. It’s not another security tool that they bolt on to the network. It’s something that’s built into Kubernetes and managed through Kubernetes and StackRox. It’s also native to the application infrastructure versus something they have to integrate in or yet another tool to watch. It just seems to be much simpler, although it’s a complex topic, but simpler thing to implement as well as manage.

    Shah: Absolutely. I mean you said it spot on. This is security that’s built in versus security that’s bolted on, and if you think about where the security industry is headed it’s all about security as code, right? Where you built it into your applications. People talk about infrastructure as code, which is what we’ve been doing for the past five years, and now we are moving to this security as code where it presents us with a unique opportunity to address security from the very beginning and forever change the security equation in our favor.

    Ashley: I’m curious. When we talk about shift left for security, I think bundled inside that, really what’s also shifting left, is auditing and compliance. Are there things about a Kub-native environment that help us with that as well, the auditing and compliance aspects of security?

    Shah: Yeah. Absolutely. When we think about compliance and, you know, shift left you want to make sure that your Center for Internet Security benchmarks cover both your containers as well as your orchestrator in Kubernetes. If you’re doing any kind of PCI or HIPAA or NIST 800-190 compliance controls you want to make sure that you extend them not just to your containers but also to your orchestrator in Kubernetes specifically. The whole shift left movement is that if I can catch an issue early on and prevent it from being deployed in my environment that is 100 times more effective than deploying it in my environment and then catching it when something goes wrong, right? So the sooner—it’s more preventative as opposed to, hey, we’re gonna detect it—let anything run in the environment; we’ll detect everything bad that happens.

    And, you know, and as we know that’s not effective. You have to have preventative solutions, you have to have guardrails in place that harden your environment so you have fewer chances of things going wrong. And that said, you also need capabilities at runtime, so despite your best efforts, when things do go wrong, you can still catch them and prevent any damage from happening.

    Ashley: Well, that’s the whole observability tracing into microservice, et cetera, understanding what’s happening in the environment. You have to know what the environment is in the first place as well as tie it back to that data.

    Shah: Exactly. And I think what we’re going to see is logs and metrics and tracing forming observability as you point out; and similarly, you know, security is just the other side of the coin, right? So observability and security go hand in hand. What we are doing is leveraging all of that rich information that is available at the node level, at the cluster level, and leveraging that to protect your applications across the entire lifecycle.

    Ashley: Excellent. Well, we’re coming up on the end of our time here. One last thought. Is there a certain best practice or something that you’ve observed as you work with customers when they begin engaging with StackRox and see your technology and what it can do for them? What is the thing that they walk away saying, “Wow, this has really helped me and I’ve solved the following problem or knowing the following has saved me a lot from avoiding some problems”?

    Shah: Yeah. So there are a lot of, you know, great resources available on our website at www.StackRox.com, and we talk a lot on misconfigurations and we’ve highlighted some best practices. For example, making sure that you use a read-only root file system, right? Because that’s a very powerful mitigation against attempts to gain foothold in your infrastructure and the adversary’s job becomes that much more difficult. Or minimize the image contents, because a lot of file systems often contain bash or package managers which further enable an attacker to do bad things, and so remove all nonessential binaries or pay attention to your Kubernetes RBAC configuration.

    Why? Because Kubernetes API is a critical attack surface. It controls what happens in your cluster and it controls what security configurations are in your cluster, and so if you minimize who has access to that Kubernetes API it prevents—it again hardens your environment, and also upgraded to the latest version because Kubernetes, the community, is constantly adding more and more security controls, they’re constantly addressing vulnerabilities that are discovered, and so running on the latest version of Kubernetes is also an important step that you can take to secure your Kubernetes environment. So there are lots of other, you know, best practices that I would call low-hanging fruit that we’ve called out on some blogs that we’ve written about, and that’s irrespective of whether or not you’re using StackRox, right? These are just some good best practices as you embark on your journey to containers and Kubernetes.

    Ashley: You do have an excellent blog and I would certainly recommend that to our listeners. Well, it’s been great talking with you. Kamal, thanks for being on the podcast.

    Shah: Mitch, thank you so much for having me.

    Ashley: It’s definitely been my pleasure. So I’d like to thank Kamal Shah, CEO of StackRox, for joining us today. You, of course, have listened to another DevOps Chat podcast and I’d like to, of course, thank our listeners for joining us today as well. This is Mitch Ashley with devopsy.kinsta.cloud. Thank you for joining us. Be careful out there.

    — Mitchell Ashley

  • Networking: The DevOps Community Deserves Better

    Networking: The DevOps Community Deserves Better

    Developers of cloud-native applications are at the heart of a process of radical transformation shaking up the business world. Using DevOps and SRE methodologies, modern development teams are bringing a level of agility to the game that is all about freeing enterprises from the shackles of the old, pre-cloud days and letting them take advantage of new opportunities at light speed.

    But the developer community has a problem. The process of developing and delivering cloud-native applications in a DevOps paradigm demands the right connectivity to back it up, and traditional networks aren’t doing the job. Cloud-native developers need cloud-native networking—network solutions that work in the same frictionless and agile way they do—solutions that put the application first and replace traditional manual network configuration with connectivity-as-code.

    To play their part, developers need application-friendly connectivity that is designed for applications composed of microservices and APIs which span many edges, clouds and service meshes. A new software only, cloud-native approach to connectivity is required to address this and other challenges such as security, performance and operational support at scale.

    There are four things developers shouldn’t take for granted in a network solution: agility, security, simplicity and performance.

    Agility

    What application developers need is a cloud-native, agile, on-demand alternative to traditional networking—something that delivers the speed to market that they need, and safeguards their profitability. With a model such as application-specific networking in network-as-a-service models, application development teams can create on-demand connectivity across edge, cloud and service mesh environments to support their apps wherever their apps travel.

    Security

    App developers require zero-trust software defined perimeter security that meets and exceeds even the most stringent compliance standards, and can be controlled as code by their DevOps tools and applications.

    Simplicity

    New networking approaches that puts the application in contol can abstract the developer and DevOps teams from the complexity of differences between underlying networks, clouds or service meshes.

    Cost-Effective Performance

    Application-controlled network-as-a-service models can deliver operational cost reduction over traditional MPLS and VPN solutions, while boosting throughput and performance compared with legacy alternatives.

    Conclusion

    Developers deserve better networking. It’s time for them to say goodbye to the old way of doing things and move on from restrictive legacy solutions with their lack of scalability, absence of agility, poor security and unpredictable overheads.

    — Galeal Zino

  • The DevOps Security Stack

    The DevOps Security Stack

    The whole idea behind DevOps is automation. DevOps automates the development process by eliminating or minimizing human error. If an error occurs, the applications fail quickly so the errors can be resolved promptly on a smaller scale. DevOps and cloud-native applications complement each other perfectly.

    Even though DevOps offers a more efficient and faster way to develop and deploy applications, security remains an issue. On paper, DevOps and cloud-native applications might be more secure than their traditional counterparts, but the reality is not that simple. With the newer, more complex, highly distributed infrastructures common to DevOps come new challenges that need to be identified and addressed.

    This article walks through those challenges to highlight what it takes to secure a DevOps workflow. I won’t focus on specific tools because DevOps is not about specific tools; rather, I’ll focus on the components of DevOps workflows that present special security challenges and explain how to address them.

    The Vulnerabilities You Just Can’t Ignore

    1. Careless use of recycled code

    One way DevOps improves developer productivity is by letting developers recycle code from previous projects or open source repositories such as GitHub. But without proper screening and sanitization, these pieces of code can pose threats to an application.

    1. Multiple platforms make the attack surface larger

    When deploying code in the cloud, you can’t use traditional security services. You need to rethink your security strategy. DevOps teams leverage various platforms, from serverless computing to microservices to multi-cloud in their applications. There’s no single solution to secure cloud-native applications. These applications are highly distributed and have various components, so organizations need a multifaceted approach to better secure these applications.

    1. The dynamic nature of cloud-native applications doesn’t help

    Cloud-native applications are continuously integrated and deployed, which makes it difficult for security teams to identify and mitigate risks. Traditional security tools can’t match the sheer velocity, scale and dynamics of cloud-native applications, leaving them useless.

    1. Secrets need to be secured

    When following the DevOps approach, security professionals need to create privileged accounts and login details and share them over business networks automatically. With serverless applications and the cloud, security teams don’t have a traditional location such as the operating system to execute security policies. A host of useful data, such as keys, storage account credentials, secrets, database passwords and embedded passwords, are stored in repositories. It’s crucial this data is kept extremely secure, as attackers can use this information to cause some serious damage.

    1. Containers can leave your applications more vulnerable

    Since the microservice approach involves a distributed infrastructure, it exposes your system to the network, which makes it easy for attackers to sneak into the system. Containers can be spread across different systems, which makes the threat landscape even larger. Containers are highly replicable, so if there is a vulnerability in one microservice, it can get replicated every time the source code is used.

    Using open source software in containers can make way for an increase in vulnerabilities. DevOps teams should make sure unauthorized containers are not used in production. These containers can be used by attackers to launch an attack on the entire application.

    1. Hosts aren’t automatically safe

    Even if containers are properly secured, the hosts they run on are vulnerable to new threats and day-zero attacks. Container runtime should be up-to-date to avoid risks that can lead to container escape. This can help attackers to take control not only of a container but also the host operating system. So, it is important that hosts are given appropriate protection.

    1. Kubernetes clusters need additional security

    Kubernetes is a widely accepted container orchestration platform. However, it’s difficult for security to be enabled at multiple layers. Kubernetes uses APIs to manage containers, and recently, it was discovered that K8’s API server is quite susceptible to attacks—attackers can make use of the API server to perform malicious activities or install malware in the application.

    Running multiple workloads on one cluster is not a good idea. Sensitive workloads should be run on a dedicated set of machines to avoid attacks through less secure neighboring applications. There’s also a need to secure sensitive metadata, which can be stolen and used to change privileges in a cluster, thereby paving the way for unauthorized changes in an application.

    DevSecOps: The Future of DevOps Security

    In traditional applications, security holds less priority, and security policies are always employed after development is completed. But with DevOps, security can’t be an afterthought. Companies depending on the DevOps approach need to make security their top priority. One of the ways to make sure security is in the foundation of a DevOps implementation is a DevOps security stack. To employ the DevOps security stack, IT teams no longer should be walled off from the DevOps team.

    Security experts’ involvement can help them gain insights into what the application is and how it’s supposed to function so they can identify risks and take steps to mitigate them. This DevSecOps approach has become popular. DevSecOps is a collaboration between the development, security and operations teams who work together to ensure security is at the root of an application, not just on the surface.

    Symantec Cloud Workload Protection: A Modern Solution for Modern Problems

    Most organizations use hybrid cloud storage comprised of workloads distributed among public clouds, private clouds and on-premises, which can lead to an increased attack surface and vulnerabilities.

    Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

    Sign up for a free trial of CWP.

    — Twain Taylor

  • The Changing Role of APM in a Microservices World

    The Changing Role of APM in a Microservices World

    Microservices usage has skyrocketed. Fully 91 percent of organizations are using or have plans to use microservices and 92 percent expect to grow their use of microservices in the coming year. It is no longer if but when: 86 percent of organizations expect microservices to be the default within five years.

    With the growing use of microservices and containers, applications have become orders of magnitude more dynamic. It’s not unusual for containers or building blocks of the application to have a shelf-life of less than a week. However, what is great for application development can create challenges when it comes to monitoring ­and diagnosing performance issues in ever-changing applications. How does application performance monitoring (APM)  change to support microservices and dynamic cloud-native apps?

    More Moving Parts

    Small, specialized microservices may facilitate shorter development cycles, continuous releases and greater agility, but when deployed across dynamic cloud infrastructure, the sheer number of moving parts also makes it much more difficult to troubleshoot application performance. Highly distributed and transient containerized components need to be tracked and measured continuously, demanding a big data approach for APM tools. To be effective, monitoring containers and microservices requires high-definition visibility across all transactions, machine learning to pinpoint problems and a shift in focus to users from servers.

    High-Definition Data

    Because the dynamic, containerized environment is constantly changing, measurement data must be collected at high frequencies—think seconds rather than minutes. Collecting infrastructure performance metrics at one-minute intervals, or longer, can distort the real situation and sometimes miss entire events altogether. For example, at low definition, a pattern of recurring but brief spikes in CPU usage will either be averaged out or not register at all—but if detected would be a tell-tale sign of a systemic configuration issue. High-definition infrastructure metrics, collected at one-second intervals, are crucial for a comprehensive view of resource utilization and shared resource dependency issues.

    However, infrastructure metrics alone are not enough. Building a complete view of the operating environment calls for data from multiple sources, including application traces, system metrics, application logs and network behavior. The resulting data set is very large, necessitating big data collection methods and processes. In-line data compression, NoSQL back-ends, non-intrusive client agents and cloud scaling are foundational technologies for modern APM tools.

    Correlating Data End to End

    Big data analytics and visualizations are necessary to process APM data into human-scale patterns and events. Identifying root cause of a performance problem often involves following a transaction from end to end, through multiple containers, shared resources and downstream infrastructure dependencies. Next-generation APM tools dynamically map the flow of every single transaction, through all intermediate relationships. Machine learning and artificial intelligence, while still in their early stages, are proving essential to finding patterns and anomalies in the data, suggesting probable causes and flagging them for human investigation. Combining the best of machine and human skills results in faster problem identification, diagnosis and resolution. IT operations teams benefit with improved application performance, reduced repair times and higher uptime even in dynamic application environments.

    Putting the Focus on the End User

    Legacy APM tools tend to focus on infrastructure components and resources, monitoring the health and utilization of servers, storage and networks. Organizations today, driven by digital competition and customer satisfaction, need to concentrate on the user’s perspective. This means monitoring multiple types of user devices for health indicators and mapping each transaction to the backend system. Automatic instrumentation delivers real-time end user metrics that trigger alerts much earlier than server-side monitoring, and enables more effective prioritization. End user insights also help DevOps and product owners track feature and application adoption rates, compare performance before and after upgrades and directly relate technical issues and investments to business priorities.

    Monitoring Apps for Today and Tomorrow

    Clouds, containers and microservices require a different approach to performance monitoring that takes into account the speed, size and life cycle of application modules. Effectively watching these distributed and transitory processes demands a big data approach that can handle the scale of end-to-end transaction data in modern enterprise environments.

    Legacy APM tools that only take snapshots result in an incomplete view of application reality and lengthen problem resolution times. Instead, modern APM systems collect a complete data set, enabling DevOps to quickly resolve intermittent and complex issues that impact business productivity and user satisfaction. They augment their skills with machine learning to quickly identify anomalies and guide them to probable causes. The results are better application performance, enhanced competitiveness and perhaps most important, increased user satisfaction.

    — Gayle Levin