Tag: cloud-native

  • Techstrong Live! Days, DC: Upskilling DevOps, Cloud-Native and Cybersecurity

    Techstrong Live! Days, DC: Upskilling DevOps, Cloud-Native and Cybersecurity

    DevOps and cloud-native are key for organization looking to accelerate their digital transformation journeys. Techstrong Live! Days, a two-day, in-person event, explores the latest DevOps, cybersecurity and cloud-native technologies and trends that are shaping the way we do business. The first stop of the Techstrong Live! Days conference tour will take place in Washington, DC on April 13-14 at the Convene Event Center. The in-person event offers educational sessions, demos and hands-on training sessions (certification available) led by top industry experts.

    Day One: DevOps/Cloud-Native Live!

    DevOps/Cloud-Native Live! is day one of the conference. The agenda for day one features a mix of topics, including API security, Kubernetes, DevSecOps, cloud security, observability and more.

    The sessions include keynote presentations, educational talks and hands-on training with leading DevOps and cloud-native tools.

    DevOps/Cloud-Native Live! features an outstanding lineup of innovators, practitioners and thought leaders, including:

    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Mike Rothman, president at Securosis
    • Jennifer Minella, founder and principal advisor, security architecture at Viszen Security
    • Sanjeev Sharma, senior vice-president, head of emerging tech and platform engineering at Truist
    • Andi Mann, CTO at Qumu
    • Steve Klugherz, vice-president of engineering at Qumu
    • Tracy Bannon, software architect and DevOps advisor at The MITRE Corporation
    • Charlene O’Hanlon, COO at Techstrong Group
    • Mitch Ashley, principal at Techstrong Research

    Day Two: Cybersecurity Live!

    Cybersecurity Live! is day two of the conference. The agenda for day two features a mix of topics, including AppSec, software supply chain security, SBOM adoption, cloud security, DevSecOps, cybersecurity threats, 5G security and more.

    The sessions include keynote presentations, educational talks and hands-on training on forensics/hacking (certification available) and API security. By attending and participating for a full day at Cybersecurity Live!, attendees will receive a certificate in-person or via email granting seven contact hours for the appropriate CEU/CPE Credits.

    Cybersecurity Live! features an outstanding lineup of security experts, including:

    • Aaron Rinehart, co-founder and CTO at Verica
    • Stephen Hendrick, vice-president of research at Linux Foundation
    • JC Herz, CEO at Ion Channel
    • Adam Fisher, principal security engineer at Salt Security
    • Carlos Asuncion, senior solutions engineer at Salt Security
    • Mike Rothman, president at Securosis
    • Charlene O’Hanlon, COO at Techstrong Group
    • Tunde Oni-Daniel, head of technology operations and engineering at OneMain Financial
    • Mike Jones, founder at H4UNT3D HACKER
    • Saad Farooq, customer success/support engineer at Traceable AI
    • Dan Gordon, director, technical evangalism at Traceable AI
    • Mark Franklin, API security solution engineer at Traceable AI
    • Brian Mengwasser, vice-president at MarketPlace & Apps Design, DISH Wireless

    Attendees will also have the opportunity to attend networking receptions each day to connect with other IT professionals, exchange ideas and learn from one another. Breakfast, lunch and snacks will also be provided to all attendees.

    Join us at Techstrong Live! Days in Washington, DC to level up your existing skills, discover new cloud-native and DevOps tools, improve the security of your APIs and network with experts and peers.

    For more information on DevOps/Cloud-Native Live! and to register, please visit the DevOps/Cloud-Native Live! website.

    To learn more about Cybersecurity Live! and to register, please visit the Cybersecurity Live! website.

  • Updating and Managing Infrastructure-as-Code (IaC)

    Updating and Managing Infrastructure-as-Code (IaC)

    Infrastructure-as-code (IaC), often embodied by open source Terraform, is an essential ingredient to cloud and cloud-native strategies. But without the ability to scale, secure and manage IaC, you very quickly experience drift. Tim Davis, DevOps advocate with env0, pronounced “N zero”, discusses establishing a single source of truth and reigning in drift by updating and managing infrastructure as code. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mitch Ashley: I have the pleasure of being joined by Tim Davis. Tim is DevOps Advocate with env0, and so, we’re going to be getting into some infrastructure as code type discussions, so, looking forward to that. Welcome, Tim—good to be talking with you.

    Tim Davis: Same for you, Mitch. Great to meet you. Thanks for having me.

    Mitch Ashley: You, too. I love your cloud off to your right shoulder, by the way. [Laughter] Anyways, so—introduce yourself, tell us a little bit about env0.

    Tim Davis: Absolutely. So, I am the DevOps Advocate with env0. dnv0 is a TACoS platform, if you will, the Terraform Automation and Collaboration Software space. We really focus on infrastructure as code, automation, teams and governance, and other tools to help you with the life cycle of your infrastructure as code environments.

    Mitch Ashley: Cool. Good. Well, you know, it’s a great conversation to have, because something that I observed always happens in our industry is, you create a new technology, it’s kinda easy to get started and starting to use, sometimes it isn’t always easy, but the complexity comes—alright, how do I scale this? How do I do this across a larger development team or multiple development teams? How do I operate it? How do I secure it through the day two kinda stuff?

    Tim Davis: Right.

    Mitch Ashley: And I wouldn’t be surprised if you told me the same is true for infrastructure as code, and in fact, I know that to be true.

    Tim Davis: [Laughter] Exactly right.

    Mitch Ashley: Let’s talk about that. What are some of the challenges once people get into doing infrastructure as code, particularly with Terraform? What are some of the challenges that you run into?

    Tim Davis: Yeah, and most of those kind of lie around the visibility and kind of the control space of that. Infrastructure as code is great. It is a fantastic way of speeding up, kind of pushing yourself into the future for DevOps, getting into that real GitOps life cycle. But with that, you know, if it usually just starts out with either one developer or one infrastructure person that starts running it locally on their laptop and figuring it out, it’s great, it does what they want.

    As soon as you start to scale that methodology and doing it locally to multiple people, that’s when you start losing that visibility of, “Where are my state files stored? Who just deployed something into the cloud? What variables might they have used for that?”

    So, it really becomes kind of an, “I don’t know who’s doing what in my cloud anymore.”

    Mitch Ashley: Mm-hmm.

    Tim Davis: So, really making sure that you’re staying on top of that, kinda centralizing everything to maintain that visibility is very important when you’re scaling it.

    Mitch Ashley: Let me ask you, then—is it fairly typical that within one software Dev team you have a person or sort of a close enough coordinated group of people that are doing the software as code, infrastructure as code. And then the confusion may exist as you start to go across multiple teams, or does it also occur within one team, just sometimes, it’s every developer for themselves and so—

    Tim Davis: Yep.

    Mitch Ashley: – you could have a wild, wild West kinda situation before you know it.

    Tim Davis: [Laughter] And the answer of that, of course, is yes, I mean, it’s all of the above. It could be even just two people on a small team that start to use these tools and they start to step on each other’s toes by having deployments that kind of counteract each other. Or you have it where somebody is deploying out into the cloud using your infrastructure as code and somebody else is just going into the cloud and clicking around and deploying stuff manually where you get something called drift, where what the infrastructure as code says is out there isn’t necessarily matching with what’s actually there.

    Mitch Ashley: Mm-hmm.

    Tim Davis: So, it can be across a single team, multiple teams—any time you really scale it past a single person on a laptop is really where you start to see those issues.

    Mitch Ashley: Yeah, okay. It’s a familiar problem, right?

    Tim Davis: [Laughter] That’s exactly right.

    Mitch Ashley: We’ve had this in other things, too. Well, what are some of the best practices or kind of good infrastructure as code hygiene to keep your worlds at least sane to start with so you—the first question is always, “What’s there?” If you don’t know what’s there, then—

    Tim Davis: Right.

    Mitch Ashley: – everything is up for grabs, or you question everything because you just don’t feel like you have a good grounding of what you’re looking at and what you’re dealing with. What are some of those best practices?

    Tim Davis: And I really—I try to stay away from the best practices thing, because sometimes what’s good for somebody isn’t great for somebody else, but that—

    Mitch Ashley: Well, and I say that as best practice is not universal, right?

    Tim Davis: Absolutely. And there are some things that you can do to help yourself out, for sure. If you’re using infrastructure as code, having the single source of truth can be very helpful for everybody, essentially stopping that drift that I just mentioned. So, if you are using infrastructure as code, save them in a repository somewhere. Make that the single source of truth where whatever’s in there, whatever’s in those infrastructure as code files, that’s what’s there.

    So, whenever you decide to go for infrastructure as code, stop using the cloud UI, stop going around and click, click, clicking and adding resources and things. Do it by updating the infrastructure as code file and then re-deploying. That can really help you make sure that you’re not causing any problems, nobody’s stepping on anybody’s toes, and you know if I see it in the files here in this one spot, that’s what’s out there.

    Mitch Ashley: Mm-hmm. Yeah, I totally agree with you. That makes a lot of sense to me. What are some of the complexities, then, you have to deal with? Because now we’re working an environment where infrastructure, the stack, the distribution of that, the locations, whether geographic or service provider really can change instantly without necessarily the full development team, which is an advantage, right? You want that sort of abstraction.

    Tim Davis: Exactly.

    Mitch Ashley: But it also can be—introduce new variables and maybe even new problems.

    Tim Davis: Yeah, and it could be new problems, it could be the same old problems, or it could be new problems that you kinda deal with the same, old way. And, you know, adding controls of making sure you’re adhering to policy, like, you’re only allowed to deploy to certain regions or you’re only able to deploy a certain number or size of instance, making sure that you have some form of role based access control there to know, you know, this person is allowed to deploy straight out to development, no problem, but if it’s going to production, it needs to wait for approval and somebody from either the DevOps team or the SRE team needs to validate everything first before we actually make that push.

    Mitch Ashley: Mm-hmm. I think something else that always happens, too, is in—you know, I’m a security guy as well as a software guy, so, I always worry about the security side of it. Now, automation can make that, you know, much better.

    Tim Davis: Exactly right.

    Mitch Ashley: Much more reliable, less human error. There’s a lot of good things that come with infrastructure as code from a security standpoint, but it also can be, it’s sort of security is in the eye of the scripter and the person who’s—

    Tim Davis: Right. [Laughter]

    Mitch Ashley: – doing, you know, configurations or doing the scripting, too, which can be good or bad. How do you address security in this kind of a world?

    Tim Davis: Yeah, and this is just one of those things where we’ve all heard the term shift left, and shifting all of these different things—security, performance, you know, billing—everything, if you shift it left into the deployment process, it really helps if you foster that communication. I mean, we know that old school term of silos where one hasn’t isn’t talking to the other hand. If everybody gets involved, if the security team is involved with writing the policy, they’re involved with double checking that it is implemented into the deployment process so that you don’t have to go and fix a problematic deployment later, it’s just stopped before it starts. That can really make sure that everybody kind of gets what they want, but security folks still have to be involved. They are still in charge of the overall process and procedure and policy, it’s just, it’s kind of a new way of getting that implemented and at what stage of the life cycle you’re implementing it.

    Mitch Ashley: Do you think it shifts—and this is actually, I just did a talk on this about shifting left of, we wanna shift everything left, which is generally a good idea, right?

    Tim Davis: Right.

    Mitch Ashley: To be able to address some of those things early and design it in, design security in, et cetera. Oftentimes, it’s interpreted as, “Let’s put that on the developers, too. Let’s have them—the developers will worry about that. The developers will worry about all those.” Now, it’s pretty much, it could be everything, sort of a ridiculous request, right?

    Tim Davis: Right.

    Mitch Ashley: Because that’s not a developer’s expertise to necessarily know all those things. What is your—when you say shift left or infrastructure as code—

    Tim Davis: Right.

    Mitch Ashley: – in practical terms on a software team, what does that look like?

    Tim Davis: Yeah, and a lot of folks think that that just means, “Hey, I’m taking away your job as the security guy and I’m gonna give it to the developer” and that’s not the case. The developer, they may be a little security conscious, they may understand the infrastructure or the networking piece, but nowhere near as much as the career security guy or the career networking and infrastructure guys. It just kind of brings them in and fosters that conversation.

    I definitely think the developers are going to be part of the conversation, because it is bringing it into their tooling, into their languages, into their life cycle, but it still requires that expertise to be able to make sure that it is done correctly, it’s implemented correctly, and that it’s being checked the way it needs to be done.

    Mitch Ashley: Mm-hmm. So, does it look like security engineers, to use that as a term, they’re sitting down with the developers, saying, “Okay, how are we configuring the environment?” and, “Here’s how you’re building your Terraform configurations”—going through that with them?

    Tim Davis: I think so.

    Mitch Ashley: Is it saying, “Here’s the principles we want you to follow”—

    Tim Davis: Yeah.

    Mitch Ashley: – “and as you’re creating this, please do these things, and then we don’t have to sit on your shoulders”?

    Tim Davis: I definitely think there’s lots of different ways you can do that. I mean, obviously, you know, having your standup meetings, making sure that they are kinda telling them, “This is what the policy should look like, however you want to implement it is fine, but this is the kind of processes and procedures, these are the rules that we need to check.” So, it can definitely be done however works best for everybody, but as long as you’re having that communication and you’re making sure that everything’s going through—yeah, you know, you can always do it different ways and be successful, still.

    Mitch Ashley: Mm-hmm. Interesting. What are some of the things that you’ve seen change? You know, there’s been a lot of acceleration over the last 12 to 18 months.

    Tim Davis: Right.

    Mitch Ashley: And, you know, I’ve heard people talk—of course, you always hear about the, as much digital transformation happened in the last year that was planned for five years.

    Tim Davis: Yeah.

    Mitch Ashley: And there is some truth to that, and I’m sure some exaggeration, too. But there’s a strong belief that, you know, people are now thinking they can deploy applications much, much faster and they’ve proved it in this last window. Have you seen that happening?

    Tim Davis: Yeah, absolutely, and you know, technology changes. They used to say it doubles every six months or what have you, and really, we are iterating and changing and kind of moving forward very, very quickly. A lot of times, we get a new tool and it’s great and then people are like, “Alright, I’m gonna pull this tool in and automate it” and then they figure out, “Oh, there’s some extra complexity here and we’re having to go back through and figure it out.”

    I definitely think there’s a lot changing, you know, even just the shift from on prem legacy, I guess, enterprise architecture through to new, like, cloud native architectures and things like that. We’re moving fast, we’re able to change and pivot and do what we need to do, but as long as we make sure that we’re kind of keeping grasp of what we’re supposed to be doing from either a security or an infrastructure construct, we can make sure that we can iterate and change and adapt as fast as possible without causing any major issues down the line.

    Mitch Ashley: Mm-hmm. Cool. What do you think the next 6 to 12 months look like? If you had to put on your crystal ball, your Magic 8 Ball, that says, “Ask Again”?

    Tim Davis: [Laughter] Yeah, I love to look into that. Obviously, it’s good to see, you know, what am I gonna have for lunch next week, but also, you know, looking into the industry of what’s gonna happen. We’re seeing more and more X as code. We’ve got infrastructure as code, you’ve got security as code, you’ve got policy as code tools. I think we’re gonna see more and more and more, you know, performance as code and things like this that just are able to bring those day two plus operational tools closer left into the deployment cycle and have all of these single source of truth in the repositories of, we know exactly what our infrastructure is supposed to look like, we know how it’s supposed to be secured, we know how it’s supposed to perform. All of this is just declaratively set up there. I think we’re gonna see a lot more of that going forward.

    Mitch Ashley: Mm-hmm. Well, certainly, as you said, it follows the “everything as code,” right?

    Tim Davis: Exactly right.

    Mitch Ashley: And if we’ve learned nothing else, I think that’s been a lesson of the past 12 to 18 months, right? It is software, it’s all about software.

    Tim Davis: It absolutely is.

    Mitch Ashley: What do you think some of the skill challenges are for people as we continue to evolve this and move into this rapid world, shifting things left, doing more infrastructure as code, and maybe asterisk as code—everything? You know, it’s always the self-learners can be at the edge of the curve, other folks have other ways of learning. How do we bring everyone along in terms of their skills and their learning, their development?

    Tim Davis: Yeah, and that’s definitely something. I mean, I ran into myself. I’m an infrastructure guy at heart, that’s where I’ve been, you know, my whole career, and eventually, someone was telling me, “Hey, this Python thing might take off” or, “I’ve heard of this thing called Terraform and it’s basically like code, but it’s our job.” And, you know, just realizing that nobody’s trying to take away your job as a security guy or an infrastructure guy or girl or what have you. They’re not trying to take it away from you and move it over to a developer, it’s just one of those things where you need to adapt to move forward faster.

    Now, it’s not just infrastructure folks that are learning to code, it’s also developers that are kind of learning infrastructure and figuring out how can I optimize my application against this infrastructure a little better? How can we work together to move forward faster? So, it’s kind of a melding of skills from different, you know, old school silos now to work together to solve the problem.

    Mitch Ashley: I made that recommendation to a network and security engineer about 10 years ago. It’s like—learn Python, and he looked at me like I had six eyes instead of two.

    Tim Davis: [Laughter]

    Mitch Ashley: And he came back from the Cisco conference, he goes, “Now I know why you said that.” [Laughter]

    Tim Davis: Exactly right. And that’s a great piece of advice even today in 2021. I mean, if you’re in infrastructure or you’re a network tech or you’re a security person, look into Python. It’s not as hard as you think and you can do so much with it. It’s a fantastic way to kind of break into that DevOps automation type space.

    Mitch Ashley: I like that, too, and not that we’re trying to make everybody a developer, but if it’s not a skill you have, it sort of leaves out this whole domain of things that you can either do to understand what’s happening—

    Tim Davis: Right.

    Mitch Ashley: – or do to automate or et cetera. It’s sort of like you’ve got one arm tied behind your back, why don’t you have two out in front where you can fully work?

    Tim Davis: Yeah. And it also helps from a cohesive understanding between groups. Back when I was a dedicated infrastructure person, myself and the development team didn’t care for each other, because we all were trying to get in each other’s way, it seemed. We were trying to solve the same problems, just going about it in different ways, because we didn’t necessarily understand the methodologies or how those people were trying to get their work done.

    If you as an infrastructure, security, or other operations person start to kind of learn the development methodologies and figure out how things work, it’ll help you to communicate and solve problems across teams better, simply because you kinda see where they’re coming from with their tool sets and the way that they do business.

    Mitch Ashley: Great. Well, it’s been a great conversation. I’m glad we got to explore this path together.

    Tim Davis: Absolutely.

    Mitch Ashley: Where can folks find out more about env0? I know you have a kind of funky spelling of env0.

    Tim Davis: [Laughter] Yes. We are at env0, E-N-V and the number 0.com. You can find us on Twitter @E-N-V-Z-E-R-O and on YouTube at E-N-V-Z-E-R-O.

    Mitch Ashley: Great. So, environment zero, right?

    Tim Davis: Exactly right.

    Mitch Ashley: Perfect. Well, hey, it’s been fun talking with you and hope you’ll come back again.

    Tim Davis: That sounds great. I look forward to it. Great to meet you, Mitch. Thanks for the time.

    Mitch Ashley: Alright, take care.

    [End of Audio]

  • Predict 2022: Back to the Future

    Predict 2022: Back to the Future

    After a year of innovation, rapid digital transformation efforts, new challenges and settling into a new normal, it is time to look back at all the lessons learned and look forward to the future. What does 2022 has in store for us? Will 2022 be a breakthrough year in terms of progress and opportunity? At Predict 2022 Virtual Summit, taking place Jan. 19-20, top industry leaders will share their speculations on what the future holds in the realms of DevOps, cybersecurity, digital transformation, cloud-native and IT.

    Predict 2022 is a free virtual event featuring a conference lobby, presentation theater, expo hall and more. This event is a great opportunity for networking and learning about the trends, technologies and looming topics that could have the most impact on technology in this new year.

    Predict 2022 features a stellar lineup of industry experts, including:

    • Tracy Ragan, CEO and co-founder at DeployHub, CDF board member
    • Mark Miller, senior storyteller at JupiterOne
    • Mike Jones, H4unt3d Hacker Podcast, content creator at Knight Ink
    • Caroline Wong, chief strategy officer at Cobalt
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Donovan Farrow, CEO at Alias
    • Nicole Dove, CIA, CRMA, business information security officer at WarnerMedia
    • Niladri Choudhuri, founder and CEO at Xellentro Consulting Services LLP
    • Emmet B. Keefe III, operating partner and founder at Insight Partners
    • Matthew Guarini, VP, senior research director at Forrester
    • Mike Vizard, chief content officer, GM/editorial director at Techstrong Group/Digital CxO
    • Mitch Ashley, CTO at Techstrong Group and principal at Techstrong Research
    • Ori Inbar, CEO at Augmented World Expo
    • Thomas Krane, principal at Insight Partners
    • Ali Khan, partner, US Consulting Solutions at PwC
    • Jim Walker, principal product evangelist at Cockroach Labs
    • Keri Pearlson, executive director at MIT (CAMS Research Consortium)
    • Russ Finney, lecturer and director of MIS Undergraduate Programs at The University of Texas at Austin McCombs School of Business
    • Marnie (Huss) Wilking, CISO, advisor, board member at Wayfair
    • Patricia Titus, chief privacy and information security officer at Markel Corporation
    • Rob Zuber, CTO at CircleCI
    • Steve Chin, author and VP of developer relations at JFrog
    • Whurley, founder and CEO at Strangeworks, Inc.
    • Chris Hughes, co-founder and CISO at Aquia
    • Tracy Bannon, senior principal, software architect and DevOps advisor at MITRE Corporation
    • Christina M. Rhylander, acquisition and policy specialist at MITRE Corporation
    • Daniel Elkabes, vulnerability research team leader at WhiteSource
    • Vanessa Pegueros, board member and cybersecurity leader at OneLogin
    • Alan Shimel, founder and CEO at Techstrong Group
    • Charlene O’Hanlon, CCO at Techstrong Group

    Attendees will be able to interact with sponsors and peers, download information and participate in raffles, giveaways and other interactive activities.

    MediaOps CEO and devopsy.kinsta.cloud Editor-in-Chief Alan Shimel will also be announcing the 2021 DevOps Dozen² Awards winners during the event.

    To check out the full agenda and to register, please visit the Predict 2022 website.

  • Mastering the Shared Responsibility Model

    Mastering the Shared Responsibility Model

    It’s no secret that cloud-native application development is growing exponentially, with Agile development, IaaS and PaaS from providers like Amazon, Microsoft and Google, enabling innovation at a pace that is challenging for security to keep up with. 

    A global pandemic and the resulting remote work mandates have only accelerated this movement. And with this change in distributed work and agile application development comes greater security considerations—and a higher degree of risk to the business. Security in the cloud is a shared responsibility, but too many organizations find it difficult to fully understand their role in the security of their applications. There are many elements of securing cloud-native applications that cannot be delegated. They require careful attention as part of a risk-based application security program that extends from design to development throughout their application development life cycle.

    With the appropriate visibility, risk-based thinking and automation, cloud-native applications have the ability to be more secure than ever, while enabling faster development and delivery at the same time. But to get to this point, organizations need to understand their responsibilities. 

    Cloud infrastructure security and compliance are necessities for ensuring how applications and data are deployed and operated in the cloud. But what about what is in those applications? Applications are made up of lines of application/infrastructure code and open source libraries built by developers, DevOps, product managers, security champions and other roles. 

    How do we know the components that make up the application are effectively secured? It is too late and not enough to solely rely on a secure cloud posture. Reducing risk early in the development lifecycle will dramatically reduce costs and business risk. Some sources have assessed the cost impact of fixing a risk in early production to be four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.

    Modern applications are delivered through sophisticated “plumbing” of secure cloud infrastructure to our device interfaces. Just as we require clean and safe water to transit the physical plumbing into our homes, we need our applications to remain secure and high-quality as they transit cloud services.

    The IaaS/PaaS Shared Responsibility Model

    The best way to think about security in this cloud-native world is by using a shared responsibility model, with IaaS customers only responsible for certain elements of the security of an application that lies on top of the infrastructure. 

    In the traditional shared responsibility model, IaaS vendors are responsible for the configuration, management and security of infrastructure elements such as networking, databases and compute engines, in addition to physical security, redundancy and more. But each of their customers is responsible for the security and privacy of everything on top of that, from design to code to deployment.

    The Traditional IaaS/PaaS Shared Responsibility Model

    The Customer Side of the Shared Responsibility Model

    What’s missing from this model are software design, code risk and CI/CD security and integrity—and these areas are the most difficult, time-consuming and require a well-thought-out and comprehensive application security program.

    With new approaches to application security, organizations can better understand the risk of their cloud-native applications and automate a significant amount of risk remediation activities at the design or coding phases before deploying to the cloud. This requires taking a broad but contextual view of AppSec across the entire SDLC—and the modern nature of attacks requires a complete view of the SDLC to understand where the most impactful business risk lies.

    Organizations must evaluate the full picture of their risk—from design to code to cloud:

    1. Visibility—Understanding your risk starts with visibility into your security and compliance risks with a real-time inventory of assets, application and infrastructure code behavior, developer knowledge, third-party security alerts, sensitive data and business impact.
    2. Secure by Design—You need to make sure that security is addressed at the design stage—before any code has been written or committed.
    3. Change Management—Organizations need to focus on the risks that matter early in the development process and based on business impact. Material changes to the applications and infrastructure should be carefully evaluated while other changes can be approved more quickly or ignored, thereby accelerating product delivery.
    4. CI/CD Security and Integrity—As an ever-running, highly-trusted and sensitive process, CI/CD is often overlooked. Many attacks in the recent past exploited this Achilles’ heel of the development cycle by embedding attackers’ code within native code commits or other automatic CI/CD processes. Organizations should ensure CI/CD operations are secure with integrity and security checks in place.
    5. App & Infra Risks Together—To properly secure your applications, you must correlate the risks of your applications and infrastructure in one platform.
    6. Automation—Automation must also be employed to limit mistakes caused by human error, ensure consistency in enforcement of policies and increase the speed of the DevSecOps process. Organizations must carefully manage this process, because automation can also introduce a new category of issues, such as race conditions, untimely triggering, incomplete state validation for edge cases, etc.

    Infrastructure-as-Code (IaC)

    The human element of risk has changed with IaaS and PaaS due to the power that cloud administrators now have. Instead of purchasing, configuring and deploying servers over a period of months, an admin can spin up a Kubernetes cluster or an S3 storage bucket, load customer data and expose it to the Internet with relevant identity and access management (IAM) policies in record time via infrastructure-as-code (IaC) using GitOps instead of ClickOps.

    The rise of IaC has enabled us to view, evaluate and respond to infrastructure changes in the same way we would any application code change. Organizations must apply the same governance rules and automation to review changes in infrastructure before they reach production, along with real-time analysis of cloud misconfiguration. 

    The main challenge is context! All IaC tools in the market today are looking at security misconfiguration as a single dimension (for example, an S3 bucket missing encryption; a cloud database missing SSL for incoming connections, etc.) and this creates a lot of noisy alerts. The risks of cloud infrastructure and the applications that run on top of it are inherently connected—it is harder to connect the dots and understand the true risk of changes than it is to accept alerts at face value!

    When securing your applications in the cloud, don’t rely on traditional tools and processes. Today’s technologies enable new approaches that help you understand and remediate risk in entirely new ways and make cloud-native applications more secure than ever.

  • What Does the Future of DevOps Look Like?

    What Does the Future of DevOps Look Like?

    During the past couple of years, we have seen a rapid acceleration of digital transformation. Many businesses have been leveraging the benefits of DevOps and the cloud to accelerate their digital transformation journeys. With so many changes going on in the industry, it is time to take a look ahead at what DevOps is becoming and how DevOps teams are managing change across the lifecycle.

    On October 27, DeployHub CEO and CDF Board Member Tracy Ragan will discuss the future of DevOps and the convergence of GitOps, event-based continuous delivery and the coming use of microservice catalogs at DevOps Experience: The Roaring 2020s Virtual Summit, during her session “Tomorrow’s DevOps Pipeline — A Radical Shift.”

    We sat down with Tracy Ragan to talk about some of the challenges that the DevOps community has been facing, how to overcome these challenges and how the role of DevOps is changing. Watch the interview below to take a sneak peek of her upcoming session at DevOps Experience.

    This year’s DevOps Experience explores how DevOps and the cloud are reinventing the path of digital transformation. The agenda for the two-day virtual event features a mix of topics, including technical sessions, deep-dives and case studies covering digital transformation, DevSecOps, cloud-native, Kubernetes, AppSec, CI/CD, open source, value stream management and more. The virtual environment features more than 50 sessions by industry leaders and an expo hall lined with booths full of downloadable resources.

    To see the full agenda and to register, please visit the DevOps Experience website.

  • The Inevitability of Multi-Cloud-Native Apps

    The Inevitability of Multi-Cloud-Native Apps

    We all know the story: Enterprises moved to the cloud. They learned about data center virtualization and multi-tenancy and self-service developer provisioning. Along came Kubernetes, and they moved to cloud-native, where they learned about automation, DevOps and infrastructure-as-code (IaC). Now, even though most enterprises are still figuring out how to do cloud-native at scale, there’s a new imperative they must master: Multi-cloud-native applications. And for almost every enterprise with a global footprint, the move to multi-cloud-native applications is not optional—it’s inevitable. 

    But before we explore why this is the case, let’s first retrace our steps. For almost every enterprise out there, the journey to the cloud started with adopting a public or private self-service infrastructure provisioning and management model. These enterprises quickly realized that this new IT model required a new set of tools to solve challenges they’d never before faced—enabling their developers with self-service provisioning, managing and operating infrastructure. Enterprises figured it out, but as soon as they figured out the cloud, they quickly had to gear up for the second phase: Automating and operationalizing an enterprise-wide rollout of cloud operating models throughout their entire developer organization. 

    Of course, this phase has its own set of challenges, and a rich ecosystem of tools emerged to address them. Even so, we all can agree that the majority of mainstream enterprises are still in this second phase. They’ve adopted cloud, they’ve expanded its use, and they’re grappling with the challenges around multi-tenancy, security, DevSecOps and governance. Hand-in-hand with this goes a whole new set of challenges around cost management. Suddenly, enterprises are faced with managing the variable costs of public cloud infrastructure: Optimizing compute infrastructure, utilization and capacity to rein in cloud spend. It’s an issue Sarah Wang and Martin Cassado took head-on in their research on the Trillion-Dollar Paradox.

    So, enterprises moved to the cloud and are now, for the most part, successfully grappling with scaling it. But nothing stays the same for long, and businesses drive IT to innovate. This is where cloud-native entered the picture to help enterprise software development teams become more agile and help businesses transform to deliver new services and experiences faster. In fact, the consumer experience this model makes possible has rapidly become the norm.

    Consistently delivering rapid software iteration across a global footprint forces DevOps organizations to grapple with an entirely new set of technical challenges: Leveraging containerized applications and microservices architectures in production across multiple Kubernetes clusters running in multiple geographies. Customers want an on-demand experience. This third phase is what we call multi-cloud-native, and it was pioneered by hyperscale IaaS players like Google, AWS, Azure and Tencent.

    The reality is, of course, that hyperscalers aren’t the only ones who have figured out how to deliver multi-cloud-native apps. Webscale innovators like Doordash, Uber, Twitter and Netflix have done it, too. To get there, they had to make and share their multi-cloud-native apps across every geography where their customers live. And, in turn, to make that happen they had to tackle a new set of challenges: Develop new tools and techniques like geographically distributed, planet-scale databases and analytics engines, application architectures that run apps on the backend close to the consumer in a multi-cloud-native way. This enabled them to do arbitrage across fleets of infrastructure capacity across regions, all while giving their customers that instant experience they increasingly grew to expect.

    What enterprises must realize is that this experience consumers have grown to expect from webscalers is rapidly becoming the same experience they expect when accessing their bank account, their insurance apps and their tax records. For almost every planet-scale enterprise, this sets up a whole new set of challenges: To span multiple clouds and multiple geographies running multiple Kubernetes clusters, you now must worry about new ways to do autoscaling, self-healing, disaster recovery, operations management and cost optimization—all of which are things that you’re just now getting figured out for virtual machines (VMs) and clusters in single regions.

    Enterprises must face the reality that cloud-native application models are not the destination but rather a waypoint on a journey to becoming multi-cloud-native. Because the consumer experiences delivered by webscalers make this the inevitable destination.

    The Enterprise Journey: Cloud, Cloud-Native and Multi-Cloud-Native

    Don’t take my word for it.

    Uber and Twitter public disclosures describe how the multi-cloud-native model is an integral part of their strategic game plan. Hybrid and multi-cloud are part of this, too, leveraging Kubernetes as a cluster manager, but they still need tools to manage all those clusters across multiple environments in multiple regions at planet scale.

    The bottom line is that the architecture that webscale companies are using today is the same one enterprises will need to adopt tomorrow to remain competitive. Alternatively, these enterprises will cede market share and relevance to the next webscale innovator to disrupt an industry. In adopting this model of building multi-cloud-native apps, enterprises will have to deal with unified access management, controlling multiple clusters, resource management and more, all across multiple regions and clusters of capacity, aggregating versus disaggregating cluster resources, using logical services that span clouds versus namespaces that span a single cluster.

    The Enterprise Solution: Planet-Scale Cluster Manager

    They will need a planet-scale cluster manager to do this; something that can observe costs, operations, performance and SLAs across clusters, across public and private clouds, spanning VMs and Kubernetes through a single pane of glass so they can operate above the clouds in an automated, easy-to-use way. Band-aid solutions like running multiple spreadsheet models to figure out how to optimize are not scalable. What’s needed are tools like machine learning to automate and optimize at scale, bin packing technology to intelligently and automatically optimize across a planet-scale infrastructure fleet and high levels of automation either with humans in or out of the loop. That’s how hyperscalers and webscalers are already doing it.

    Every planet-scale enterprise is multi-cloud-native, running data-driven apps. It’s not a fiction: It’s already happening across webscale companies, not just hyperscalers. Multi-cloud-native is the path that every enterprise is going to need to follow if they want to transform themselves to compete with the next webscale upstart. The good news is, the pioneers have left us a map to follow.


    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

  • Mastering API Gateways for the Modern Cloud-Native Enterprise

    Mastering API Gateways for the Modern Cloud-Native Enterprise

    As modern enterprises continue migrating to the cloud and the need for connected applications and devices dramatically increases, API-driven architectures are being widely adopted. In addition to the convenience of being able to efficiently connect and share resources, organizations benefit from the innovation and accelerated development speed that APIs bring in multi-cloud environments. APIs are not new, but as more enterprises adopt modern application architectures, they are increasingly occupying a large amount of a software development team’s delivery efforts. 

    When enterprises modernize and migrate to the cloud, it’s natural that challenges arise which need to be tackled before they become pain points—especially when it involves a complex microservices environment. API gateways are an essential ingredient that helps businesses overcome many of the challenges associated with APIs. API gateways are deployed at the edge of an infrastructure, responsible for routing client API requests to backend microservices. Modern API gateways also come with additional perks organizations can benefit from as teams and infrastructure grow simultaneously. 

    Let’s take an in-depth look at some of the major challenges organizations face around APIs, and how to maximize their benefits.

    Rapid Adoption Meets Growing Pains

    API-oriented architectures greatly accelerate the agility of an IT department, as they’ve become a well-known pattern for modern application architectures. However, this approach can be deceptive, as many critical issues and concerns around APIs aren’t always apparent from the onset. If they are not properly identified, they become growing pains teams have to face on a daily basis.

    The first challenge is the need to authenticate users when they make requests. API gateways allow organizations to integrate and consolidate authentication providers using their protocol(s) of choice. With billing and analytics, organizations need to understand the number of resources consumed when processing a transaction and how their customers consume their APIs. API gateways become the natural point at which to collect this data. 

    In terms of DevOps initiatives, some API gateways use service discovery to configure themselves dynamically which greatly accelerates a development and ops team’s velocity when shipping new features or fixes. To help teams deliver a highly available and resilient platform, API gateways are enablers that provide them with the puzzle pieces for advanced load balancing, rate-limiting, circuit-breakers, mirroring and more. These components make the DevOps mindset a reality. Teams can scale them as needed to realize production-grade environments, continuously updating deployments with software changes and avoiding any unintentional single points of failure (SPOFs). 

    In recent years, the evolution of API gateways has solved growing pains in the cloud, helping organizations leverage cloud-native technologies and workflows. Combining cloud-native technologies with an API-led integration platform creates an effective architecture for a digital enterprise to increase productivity. Automating production, operation and services is no longer a goal but a must-have.

    Modern API gateways features within this environment go well beyond what one would expect at first glance. API gateways can be the cornerstone of a deployment strategy transformation. With hundreds—if not thousands—of services to continuously deploy, the risk of introducing a regression to the platform soars, and being able to address this problem immediately is not enough. API gateways can help you transition to modern deployment strategies and blue/green or canary deployment becomes commonplace—helping deployments become an easily managed daily task.  

    API Gateways to the Rescue for Cloud-Native Architectures

    As part of the shift to modern application architectures, enterprises should invest resources in implementing API strategies as part of their software development initiatives. In turn, they should leverage API gateways to alleviate growing pains and simplify delivery efforts. APIs should be secured, managed, observed and even monetized. 

    API gateways can also help with critical issues related to authentication, security and SSL, billing and analytics, life cycle management, high availability and resilience, and they can even help you initiate a culture shift toward a DevOps mindset. By combining API-driven architectures and cloud-native technologies, organizations emerge with an effective architecture for the digital era. API gateways help overcome the challenges and unfold the networking intricacies of today’s cloud-centered world.

  • Securing Microservices Vs. Monolithic Apps

    Securing Microservices Vs. Monolithic Apps

    New requirements for Securing Microservices Vs. Monolithic Apps

    Enterprises are migrating from monolithic applications to microservices, hoping to accelerate software deployment and improve scalability. Security is sometimes glossed over in these transitions.

    Simple best practices like authenticating users and using SSL are still important to follow. But teams need to think through important differences between the two architectures to ensure new risks are not inadvertently introduced.

    As you begin  migrating from a monolith to microservices, some of these issues may seem relatively trivial. But left unaddressed they can create substantial security vulnerabilities, reduce performance, and result in technical debt.

    Some of the most important differences to consider include the number and size of attack surfaces, and how and where teams manage business logic security. Teams also need to think through the additional complexity of increased communication between microservices running in separate containers or machines. New issues also need to be addressed when application state is stored externally.

    1. One Larger Versus Many Smaller Attack Surfaces

    The biggest difference relates to the size and number of attack surfaces. A monolithic application is by definition a single application with a single attack surface. In contrast, a microservice architecture spreads the same functionality across multiple, independently running microservice applications, each with their own attack surface.

    The attack surface on the single monolithic app is also larger than on each microservice because the application has far more responsibilities to control.  In contrast, the attack surface of each microservice is much smaller because they are limited in what they can do. In traditional web application security, a web application firewall can protect the entire application in aggregate. With microservice security, however, teams need  to think about securing the connections to each microservice using a more adaptable firewall.

    2. Managing Business Logic Security

    Web application firewalls provide a front line of security to track what clients are requesting data and ensuring they have the appropriate credentials. Monolithic applications often add an additional layer of business logic security using a servlet. This performs logical filtering within the app itself to ensure requests are reasonable before passing them to the appropriate component.

    As a result, monolithic app components can operate on the assumption that the request has been validated at the application programming interface (API) level by the servlet. The servlet can keep track of who is making calls into the application and block requests that fall outside the bounds of normal behavior. A microservice rarely if ever has any idea about what has been done between other microservices. They are typically designed to operate independently from the details of everything around them, which means that business logic-level attacks are easier to perpetuate.

    3. Service-To-Service Complexity

    In a traditional monolith, messages are passed between functions within the application. In a microservice architecture, this traffic passes between multiple services that may reside behind a common firewall or separate firewalls.

    Developers may mistakenly believe these communications are safe when the messages are passed between services that exist behind a common firewall. But because of the dynamic nature of microservices, sometimes these communications are passed over wider networks. There can be security issues when data is passed between applications in plain text.

    Teams should consider encrypting data in transit as it is passed between microservices, and then encrypting data at rest when it is stored.  This encryption requires teams to think about creating an encryption process that runs in conjunction with provisioning and managing microservices. Each service needs to be provisioned with a public certificate and private key. There also needs to be a method for revoking  certificates and issue new ones when services are decommissioned or compromised.

    4. Authentication Latency

    Microservices can also increase the number of authentication steps required to execute a transaction. In traditional application security, an API security service only needs to secure one link between client and server.   With microservice security, additional consideration needs to be given to securing the connection from a client to each microservice and to the calls between them. This increases the number of security steps required for requesting and processing security tokens. Unless this process is efficiently engineered, each request can add latency and degrade performance.

    Some organizations may skip some of these steps, under the assumption that these services are communicating on a secure virtual private network. However, this can increase app vulnerabilities if the network is compromised. Another approach lies in implementing a better strategy for API security.

    5. Immutability

    Monolithic applications manage data as part of their operations. In contrast, microservices are architected so all data is stored external to the microservice, which is called immutability because the service does not change state. This makes it easier to spin up new instances or kill running ones without affecting the application as a whole. But because the microservice itself does not change, an external process needs to maintain a list of which microservices are allowed to talk to others. These need to be managed centrally and then either pushed out or pulled in to each microservice automatically.

    Another challenge is data integrity. In a traditional application, the state of a transaction can be monitored internally; if a step cannot be completed the entire transaction can be rolled back. In a microservice architecture this kind of state management needs to be managed externally.

    6. More Services To Monitor

    Traditional infrastructure-based monitoring was designed for providing endpoint and server security. Microservices generate more traffic between services at a finer level of granularity,  which can make it harder to automatically enable application observability through metrics, logs, and tracing. This is difficult enough just for measuring operational health, and even harder for tracking security posture.

    Another challenge confronting security designers lies in ensuring consistency for application observability data generated across microservices. At the least, security requires good logging and integration into incident response systems to alert security analysts to the possibility of subtle and slow-moving security breaches. More sophisticated approaches can combine these richer data sets with machine learning to help detect and block attacks without burdening teams with false positives.

    Planning for a New Security Posture

    None of these security concerns should be deal breakers for transitioning to a microservices architecture. But as enterprises begin to scale up their microservices implementation, these issues will grow in complexity. A little planning upfront could reduce the need for significant rework down the line.

    Security tools such as Traceable’s Defense AI are emerging to address these challenges in a more automated way. The key lies in balancing the appropriate set of rich observability data and machine learning, with a deep understanding of the rapidly evolving API threat landscape.

  • Open Your Ears and Get Ready to Listen: Cloud-Native Days with Kubernetes

    Open Your Ears and Get Ready to Listen: Cloud-Native Days with Kubernetes

    If you think all the way back to primary and secondary school, you may remember hearing something like, “open your ears while your teacher is talking to you.” It’s true that someone tuned in to listening learns more than someone who doesn’t, but opening your ears is a lot more important than that. Open ears have the ability to open minds. And with the tech industry constantly changing it’s more important than ever to keep your ears—and your mind—open to change.

    With Cloud-Native Days with Kubernetes approaching, attendees have the perfect chance to open their ears and listen to the best of the best in the tech industry. Cloud-Native Days with Kubernetes is a two day virtual summit boasting over 50 speakers and sessions led by industry thought leaders and doers in the cloud-native space. Attendees will walk away with a better understanding of cloud native, its impact on the IT landscape and a lot more after listening to the key practices and methodologies of these tech titans.

    While there are a myriad of talented speakers at Cloud-Native Days with Kubernetes, there are two very special keynote speakers you’ll want to pay extra attention and listen extra closely to. Hosting keynote sessions Aug. 4 and 5, Tara Hernandez and Caroline Wong are prepared to talk about technology shifting and the future of cloud-native security. With loads of experience and sage advice, Tara and Caroline are without a doubt the top two tech experts you won’t want to miss.

    If you’re unfamiliar with Tara Hernandez, she’s a senior engineering manager at Google Cloud Platform, Associate Board member of Women Who Code and the host of the 12 episode podcast series, ‘Women Who Code’. A specialist in software engineering infrastructure and early backer of the Continuous Integration revolution, Tara has done everything from developing developer tools such as Tinderbox and Bugzilla, working at Pixar Animation studios to reinvent development infrastructure to handle the challenges of writing software in a film production environment, and helping create cloud developer platforms at Google. Beyond being a wizard in her field, Tara is equally impressive in her drive to share useful things about engineering management. 

    No-one’s journey goes without its challenges. But for Tara, “One issue [she] has faced in her rise to success is a case of imposter syndrome. While she has always had the skills to overcome any challenges that came her way, it took a lot of work for her to develop mental self defenses, and tame the anxiety that came when she was presented with a project […] Getting involved with [Women Who Code] has made her aware of the need for advocacy at a grassroots level, and she’s become more confident brainstorming with peers and management teams about increasing diversity in her own work place. At the same time it’s helped her find the confidence to attend more conferences, and even start giving talks.” A supporter, advocate, mentor, and “shining example of someone who has overcome doubt to achieve success,” Tara is the ultimate speaker to inspire change and innovation, especially in creators. 

    Check out Tara’s podcast ‘Women Who Code’ and listen to her talk about the current state of DevOps here to learn more before her talk, ‘Those Little Tectonic Shifts,’ Wednesday Aug. 4 at 12:45 p.m. EDT. 

    Cloud-Native Days with Kubernetes is also incredibly proud to host Caroline Wong, Chief Strategy Officer of COBALT. Caroline is also an author, teaches cybersecurity courses on LinkedIn Learning, and similar to her fellow keynote speaker, hosts the ‘Humans of InfoSec’ podcast. With a background in communications and cybersecurity, Caroline holds deep-rooted expertise every attendee will want access to. 

    As Caroline says, “Cloud native is here; it is scaling, and it is not going anywhere. The more we can see the reality and necessity of what security must become, the better we will all be in the long run.” In her talk, ‘The Future of Cloud Native Security,’ Thursday Aug. 5 at 11 a.m. EDT, Caroline will share her observations on how companies must change the way they build security into their cloud-native projects, forecast what’s next for cloud-native security, and how organizations must double down on people and process innovation to overcome the misconceptions, education gaps and common mistakes we see when it comes to the cloud.

    Be sure to check out Caroline’s podcast ‘Humans of InfoSec’ here before joining her keynote session next week.

    It’s always important to listen. But when listening means driving ideas forward, opening your ears can be the most beneficial tool to be better than we were yesterday.

    So open your ears, get ready to listen and join us Aug. 4 and 5 at 9 a.m. ET for a much needed active listening experience! Register today.