devopsy.kinsta.cloud

Tag: cisco

  • DevOps Chat: DevOps and the Programmable Network with Cisco DevNet

    DevOps Chat: DevOps and the Programmable Network with Cisco DevNet

    Network technology has undergone its own transformation in parallel with cloud infrastructure, how we create software and the adoption of DevOps. SDN, NFV, virtual network appliances and an ever-expanding suite of APIs make network and security technologies much more accessible to developers.

    Network engineers’ worlds are rapidly changing, too. From highly skilled to associate-level, all network engineers are faced with building up a new and necessary skill: software development. Learning software development can be a daunting, intimidating proposition even for someone already skilled in the network engineer domain.

    So, how do we lift up the community of network engineers and help them build their development chops? How can software and DevOps engineers easily get access to all the programmatic interfaces that configure, manage and control the network?

    These questions and more we explored with Susie Wee, founder, senior vice-president and CTO of Cisco DevNet. DevNet is an online resource full of information for app developers, infrastructure developers and network and DevOps engineers. On DevNet, you’ll find training (Python, API and more), sandboxes for experimentation, code exchanges (including GitHub), CI/CD and new Cisco certifications for software.

    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 Susie Wee, founder, SVP and CTO of Cisco DevNet. Our topic today is a really interesting one—DevOps within a programmable network. Now that we can program the network, what does that mean to the DevOps world? Susie, welcome to DevOps Chat.

    Susie Wee: Hey there, Mitch, it’s great to be here. Thanks for having me here.

    Ashley: Thank you so much for joining us. Hey, would you start out and just introduce yourself to our audience, tell us a little bit about what you do and what you do at Cisco DevNet?

    Wee: So, I’m at Cisco, and as you said, I founded DevNet, which is Cisco’s developer community—and you might be wondering, “Why does Cisco have a developer community?” It’s because the network has become programmable, and we’ve been really driving that whole portfolio of networking to not only be software and hardware, but you know, to have both. And the fact that the network has APIs, the fact that the network is programmable means that there’s a fundamentally different way to leverage the network. And the thing that we recognized more than five years ago is that we are going to be pushing our technology portfolio towards software, towards programmability, towards having APIs, but what that also means is that the people who operate networks and the people who interface with networks need to learn about that.

    Ashley: Mm-hmm.

    Wee: So, in addition to building our products in a software and programmable way, we had to bring our community along as well, so we formed a developer community for Cisco, and that’s what DevNet was all about. It’s our developer program that builds our developer community, and when I say developer, I actually do mean software developers and the way that we think about software developers—people doing DevOps, people writing applications—but I also include networkers and specifically networkers who are running networks who need to learn some software capabilities so that they can use the programmable network.

    Ashley: Interesting. I was sharing with some friends several years ago, maybe nine years ago, a network engineer asked me for some help with career development and the first thing I said was, “I think you need to learn Python,” and of course, he wasn’t familiar with that, and he went to a Cisco live event and heard about the visualization of the network and programmability and came back all excited. And, of course, I didn’t have much to hand him other than, “Here’s a Python book.” I don’t know what APIs are available yet, but things have, of course, evolved greatly.

    How would you describe where we are today and what’s the way to get started and get going with this?

    Wee: Excellent. Well, the thing that I’ll tell you is that you are a visionary to have given him that advice five years ago. [Laughter]

    Ashley: Check is in the mail, I’m writing it out now. [Laughter]

    Wee: [Laughter] Check is in the mail. And basically, now, you actually would have somewhere to send him to, which is to DevNet, the reason being is that, you know, if you go to Developer.Cisco.com, and everything in DevNet is in Developer.Cisco.com, we have all of these free resources, like coding resources, learning resources, learning about APIs. Python is definitely fundamental to what we’re teaching, because we’re recommending that we use that as actually our base language and, obviously, people can use any language that they want, but it’s a great tool set to start out with.

    And, you know, in addition to Python, there’s of course just using all of the software development tools that we want people to use like GitHub, Postman, you know, just your favorite code editor. So, we have a whole bunch of, just, regular software tools that we wanna make sure our networkers are familiar with. We want them to understand the practices used in software, you know, just code sharing, right? So, just using GitHub repos, and using it not only for sharing code, you can actually use it to share network configs and check network configs and use it in CI/CD pipelines.

    So, there’s a whole bunch of ways that we want the networking industry to use software practices and software tools. And so, at Developer.Cisco.com, we have learning labs, and we have StartNow, like, Developer.Cisco.com/StartNow is a place for that networker to get started with software to get started with our APIs. But in addition, we have stuff for advanced software developers as well. Like, if they wanna get in there and just start programming a network, doing some automation, using advanced security services and things like that, we actually also have a DevNet sandbox. You know, if you wanna play around with this world, you might not have a bunch of kit in front of you to start coding.

    Ashley: Sure, yeah.

    Wee: And so, with the DevNet sandbox, you can actually make reservations to real networking gear, real security products, real collaboration products—things that you can actually get active with right away to, you know, even test out your advanced coding and advanced networking needs.

    Ashley: Well, it’s interesting, because it seems like—I mean, you understand software, coming from your background with HP and all the work that you’ve done. You’re really trying to marry these two different disciplines about how software folks think of the world, you know, sort of a GitHub of networking kind of attitude about tools and how to learn and downloading code segments and things that’ll help you experiment with what may be a CCIE or a CCNA engineer has experience with in their certification training where they’ve got a sandbox lab, that they don’t have to create their own physical lab—kinda married those two worlds together.

    Wee: We have, and it’s super interesting, because when we talk about who will run the IT system or the DevOps kind of platform and infrastructure of the future, will it be the CCIE networker, you know, who really knows how to run mission critical networks and keeps these things up 24/7, you know, many nines of reliability? Or will it be a software developer who really understands the software skills, can code up hundreds of lines of code a day? And really, what we’ve come to, you know, in watching people who move to automation and things like that is, it’s a combination of both. You’re gonna want someone who really understands networks, [Laughter] you know, to that really professional level.

    Ashley: Mm-hmm. Oh, sure.

    Wee: And you’re gonna want someone who can code. You might find the unicorn that does both and knows both of them to the level of, you know, of a CCIE networker or the advanced software developer. But chances are, you’re gonna have a set of folks working together. You also want the networking tools to be simplified so you don’t need that really high level, and there’s a lot of automation that occurs. You know, so if you’re kind of a smaller outfit or growing in another way—but oftentimes, you’re gonna want these groups to be working together, and that’s what we’ve tried to hit with DevNet.

    Ashley: Well, you know, what you describe is, I imagine you’re leading towards something that looks like what DevOps is today or DevSecOps including security as part of the DevOps suite of everybody working together. What does the NetOps or the NetDevOps world look like as you’re helping folks move out of the networking centric world and the software centric world to where that’s blended together?

    Wee: Yeah, so, I—and I think that the importance is that we do the blending so that we can take the best from both worlds. I see it as pretty flexible, and once again, whether it’s all embodied in, you know, one person, the unicorn who learns it all, [Laughter] but more likely is that you have the right level of instructions and you have people who can interface together.

    So, one of the new things that we actually just announced last month, or in June at Cisco Live, is a brand new Cisco certification that is a Cisco DevNet certification

    Ashley: Excellent.

    Wee: And what happens is—actually, I have just all the respect in the world for the networkers of this world, and there is 1.7 million Cisco certified professionals, like, people who have earned a Cisco certification in the world. And basically, they know all about networking. And Cisco certifications have been out there and if you’re a CCNA associate level, professional, CCNP or the highly revered expert CCIE—now what we’ve done is, with Cisco, we’ve created the Cisco DevNet certification. So, we have a Cisco DevNet associate level, professional level, in the future we’ll be announcing the expert level as well. And this is bringing that set of software skills to networking.

    And so, if you go and take a look at Developer.Cisco.com/certification, you’ll see that it’s actually all of the software tools that you would need to learn.

    Ashley: Right.

    Wee: So, you know, using rif APIs, using APIs securely, using authentication. So, it starts from fairly beginning software, but in a rigorous way, and gets up to fairly advanced software topics as well. And what that does is, that helps train up the software folks or at least validate the software folks who already have those levels so that they can work together.

    Now, the way that we designed it is that our networking certifications are 80% networking, 20% software. Our DevNet software certifications are 80% software and 20% networking.

    Ashley: Okay. Interesting.

    Wee: We’ve done that so that these folks can work together, you know? And so, there is a little bit of networking that you’d have to learn, but enough that you could be effective in it, that you could really deliver these systems, that you could write automation software for DevOps pipelines that leverage the programmability of the network. So, it’s a pretty important part of what we’ve done here.

    Ashley: Well, you’ve created, really, an exchange by focusing on automation as a core use case. So, coming to software can be really daunting, right? I need to learn this language, I’m not even sure what problem I would solve with software, how I would write something to do something with software. So, it can be really intimidating, so I really like how you’ve laid out automation as a key subject area, use case for people to collaborate on at the site where they can share their code and get [Cross talk], right?

    Wee: That’s right. So, what we did was, also in June, you know, we announced the new DevNet certifications, but we also announced the DevNet Automation Exchange. And basically, what we recognized is that automation is our customers’ biggest problems. So, basically, anybody who just has any type of infrastructure needs to work on automation, because their infrastructure has grown, their businesses have grown, they’ve had to scale out their infrastructure. And what they need to do is automate it. And this goes all the way to even manufacturing companies, right?

    Ashley: Sure, yeah.

    Wee: So, you’re digitizing, you need to automate your IoT, you need to automate your collaboration, your systems, you need to automate just your compute and your network.

    So, automation is the biggest problem and what happens is, Cisco’s products—well, actually, in many products around the world for infrastructure—our software product, they use SDN, virtualization, they work in a software world, containers, microservices, everything there. But, as we get there, next, what you want to do is, you want to be automating your infrastructure overall. And as we want people, it’s one thing to say, “Okay, here’s all of our products. Our products now all have APIs.”

    Ashley: Right.

    Wee: You know, so our routers, they’re all programmable, it’s just, at the device level itself.

    Ashley: REST APIs, even—yeah!

    Wee: We have controllers—REST APIs throughout. We also have controllers, you know? So, controller level that abstracts out and interfaces with the individual network devices and the security products and everything there and let you work at that next level. But, as you’re working on all of this, you know, people have said, “Okay, great, Susie! With DevNet, you guys have taught us how to code. You’ve taught us about your product’s APIs, but next, we want help solving our automation use cases.”

    Ashley: Mm-hmm.

    Wee: And so, what we did was, we created automation exchange to be the place where we’re using community software, so we have code in GitHub and we encourage our community to submit code in GitHub, and it’s a code exchange that we put in there to solve real automation problems.

    Ashley: Mm-hmm.

    Wee: And so, what we’re trying to do is, you know, we’ve seeded it with 50 code repos, and that’s all different automation use cases. We’re inviting our community to submit more, and you know, just use it as an exchange where Cisco’s community, we have the best infrastructure experts around the world who’s, you know, working on DevOps, working on IT, working on compute, and working on networking, of course, and security. And what we want is, we want them to get together and have a place where they can exchange code to really build up that automation repository to make it easy for them to do their thing.

    Ashley: Mm-hmm. Well, let’s look at this from maybe a 180 degree view. We’ve talked about it from a network engineer’s perspective. If you’re a software engineer doing DevOps and maybe doing DevSecOps, but you’re living in containers—you had mentioned Kubernetes, microservices—

    Wee: Yep.

    Ashley: you know, cloud or maybe even the Cloud Native world—how would you look at this? Is this something that they’re gonna be interested in, or how would they approach it, or why would they approach this as something they wanna tackle?

    Wee: Yeah. So, first of all, the answer is yes, they should be looking at it. There is both the set of DevOps folks and the set of app and cloud developers. You know, so, even if you’re in DevOps, you’re kinda scaling out your system, you’re working on that portion of it or if you’re the actual app developer or cloud developer who is developing the applications, the microservices and everything that runs on top of it.

    Ashley: Mm-hmm, right.

    Wee: In both of those worlds, what happens is, there is this opportunity right in front of us, because—and I say opportunity because most of them have not yet realized that the network is now programmable.

    And so, what has happened is, people are used to the fact that your compute is programmable, we use virtualization, kind of everything in that world, but the world is just starting to realize that the network is programmable as well. Yet, you know that every time you scale out an application, as you reach the cloud, security becomes a concern, the connectivity becomes a concern, the way you connect up your databases to your applications and make sure that the right devices and users have access to the right stuff—that’s all core to how you’re building up these applications and your Cloud Native applications and everything there.

    But the thing that we realized, that people can realize now is that—oh, the network is programmable. I can actually get, for example, a network level of security or use the network for a network layer of access control that is even, you know, that adds another level of kind of control and security than working at the application level alone.

    Ashley: I would think there’s, too, some good analogues that they may be used to in a cloud world, like virtual load balances, firewalls, things like that that they may have been part of setting up in their DevOps world.

    Wee: Absolutely. And what happens is, with the new—like, when we talk about a controller on top of a network, so, it’s one thing to say, “Oh, there’s just a controller that lets me abstract what’s underneath it,” but the other shift is that you can actually use policy, and that’s policy you use in compute all the time. But just set up policy to say, “These users or these devices have access to these applications and have access to these applications to this data and these databases and everything there.”

    And you can start to set security policies for access and for your applications in ways that then uses the programmable network underneath it. So, you can, at the detailed level, set up a VLAN that segments out, [Laughter] you know, the right amount of the right part of your network and data and application to give you that next level of security.

    Ashley: So, Susie, you talked about automation as the key use case. That’s a pretty big topic, though, and I’m curious—how would someone get started working on automation in a network that they’re running, they’re managing as a network engineer professional?

    Wee: Yeah, that’s a great point. So, really, you know, automation, while we all strive for automation in this perfect world, the question is, how do you get there? And especially, how do you get there when you have a live system, you know? So, when you’re running DevOps, when you have a large infrastructure, you have things running on it all the time. And so, the question is, how could you get there?

    You know, one thing that we’ve done with DevNet automation exchange is that we put use cases on there—use cases that help people get started. But what we’ve done is, we’ve actually categorized it into this walk, run and fly approach.

    Ashley: Okay.

    Wee: And the way that we say it is, with walk, like, how do you get started with automation is first, you’re gonna walk. Like, first use it in your network or in your infrastructure as a read only kind of a way. Try to get visibility and insights into what’s going on, perform analytics on that, get all of the insights that you can from your running infrastructure or from your running network. And then we have a set of use cases for walk.

    You know, run is when you’re ready to go to this next level where you’re ready to push out a control or push out a policy, you know, actually set something on your live system.

    Ashley: Okay.

    Wee: And so, then you have your kind of run. And then fly would be that ultimate DevOps workflow, you know, where you’re in that full workflow of you’re proactive, you’re monitoring, you’re managing, you’re getting insights, you’re analyzing, you’re pushing changes out, you know, you’re proactively seeing where do you have opportunities to load balance, fix things, deploy things, put in more security to identify threats and everything there.

    So, you know, of course that’s the ultimate case of where you wanna be with the full DevOps workflow, but to get there, you need to take those steps. So, it’s pretty fun to have these use cases that help you walk, run and fly.

    On the networking side, an example of the walk is something that you always have to do in networking if you’re running a large network is, you have to continuously be auditing your network.

    Ashley: Right.

    Wee: You know, if someone reconfigured something in there, they added a device, they changed a setting and what that’s doing is now saying, you know, a threat to your network. So, you know, for auditing, what happens is, if you move things into a software, actually, a DevOps kind of workflow, what you can be doing is taking your network configs across all of your devices, putting them all into GitHub, [Laughter] so that you’re actually taking your networking configs, looking at them with, you know, in a code repository looking at version control.

    You could actually be running Ansible playbooks where you’re continuously kind of running through, making sure you haven’t gone off the golden template, be looking for issues, and then just let people know—hey, something is off here. It’s read only, but you then let your ops team know, hey, there’s something that’s not right. And just moving that into a software workflow is way better than what most teams have to do today.

    Ashley: Well, usually, they’re totally separate worlds, and now you’re talking about being able to integrate those in a CI/CD kinda workflow, you know?

    Wee: Yeah.

    Ashley: You know, a tool chain that manages not just software DevOps but the network ops.

    Wee: Yeah, exactly. And then you push that capability over to the run side, like, if you want to—if you’re talking your wireless network, you wanna set up guest networks or shut down networks or run, I’m imagining you have stores around the world, right? If you wanted to run that, then what you can do is push out your SSIDs, start them, stop them, reset your guest passwords and everything, automate all of that to where you’re pushing out control.

    And then, you know, what’s really fun as a fly use case is just doing DevOps. Like, so, if you have new applications and a new class of applications that you wanna deploy onto your infrastructure, then you wanna do it securely. So, let’s say that you have a new set of applications, you want it to touch your financial database, you only want a select number of employees to access it, you wanna make sure that what your applications are running on, where your data is stored is all working in the right way, you can actually set network level configurations to segment your network, set up the VLANs, get your applications deployed into classes.

    And so, we have something called ACI to help be an application centric infrastructure so that you can actually map your application settings down into your network configuration settings and do all this with a full DevOps CI/CD pipeline. That’s the kind of thing you could do in a fly use case. So, we actually have code for all of this stuff that lets people jump in, get started with it, and then customize it into their own system.

    Ashley: One thing that is really great about this is probably the network world doesn’t quite yet realize how much of this has already kinda been worked through in a DevOps world, and there’s so many resources in thinking about tool chains and workflow pipelines and tools to manage all of this.

    Wee: Exactly.

    Ashley: They may not necessarily be able to lift and shift right onto a network paradigm, but pretty darn close.

    Wee: Absolutely.

    Ashley: So, they’ve got a big leg up that they may not even realize yet.

    Wee: Yeah, absolutely. And it actually, it kinda goes both ways. So, we’re actually not claiming to do rocket science, right, in terms of something very new. In some ways, what we’re doing is, we’re connecting the world so that you can take the best practices from both worlds and put them together.

    Ashley: Fantastic. Say some more about the certification part of that, because I know that’s extremely valued, you know, if you’re at that CCIE level. That’s a prestigious thing.

    Wee: Yeah! What’s really nice is, you know, once again, I’m kind of honored to join—to my predecessors who’ve actually created the Cisco certifications, because that CCIE is such a high level of expertise, and everyone who’s a CCIE, I just bow to them [Laughter] because of how hard it is to earn that.

    Ashley: Oh, it’s a huge amount of work, yes.

    Wee: But what I also wanna talk to is that, when you take that highest level networker, someone—you know, or any level, whether you’re a CCNA, CCNP or CCIE, the highest level, if there’s sometimes amount of software skills that you could pick up. So, you could actually start with a DevNet Associate, and really, the idea is that you learn enough about software so that you know the modern tools so that you could leverage software and DevOps tools and really get familiar with that side, and then you could get a coder next to you that you could direct in a good way.

    Ashley: Mm-hmm.

    Wee: But what’s neat is that we have, we actually have these coding 101 sessions that we give to folks. And really, what happens is, if you’re a networker, and you have this level of expertise but you’re not coding as your day job, you just don’t know the tools that you use today, that are used today.

    Ashley: Right.

    Wee: And what we do is, we will just walk through, like, every tool and say, “Hey, we’re not going to the next page ‘til everyone gets this set up,” Right? [Laughter] And, you know, it’s just getting in there, again, using GitHub, using Postman, making sure that you can download Postman collections, that you’re getting your authorization tokens and that you’re setting things up correctly. And we don’t go to the next page ‘til everyone gets past that first step, right?

    Ashley: That’s why everybody starts with Hello World, right?

    Wee: Yeah!

    Ashley: I guess in the networking it’s, what, a TCP session established is your Hello World or something. [Laughter]

    Wee: [Laughter] Exactly. And so, we have a group of CCIE advisors, and these are people who are top of their game, but we’ve even selected them to advise us.

    Ashley: Well, I really appreciate having you on the podcast. We have a great community of DevOps, DevSecOps, people doing software, and I think we can play a key role in helping you with what you’re doing with Cisco and DevNet and bridging that gap. We’ve started that process here today, you know? It takes that first step, and I feel like we’ve made that.

    Wee: Yeah, absolutely!

    Ashley: Thank you for doing that with me.

    Wee: No, thank you, and if I can actually, just as a message, just to reach out to the audience and say—you know what, please come to DevNet. Because DevNet is not only for networkers, it provides you a way to interact with networkers, but I would love to have you join the DevNet community and give us thoughts on how can we make the programmable network even more useful to DevOps, to DevSecOps and to achieving everything that you want?

    Ashley: Well, Susie, thank you so much. We’ve completed another DevOps Chat podcast. I’d like to thank my guest, Susie Wee, SVP and CTO of Cisco DevNet for joining us today. Thank you, Susie.

    Wee: Great! Thank you so much, Mitch. Thanks, everybody.

    Ashley: Wonderful. And thanks to you—to you, all of our listeners—for joining us today. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • Cisco Unleashes the Capabilities of the New Network

    Bringing software skills and software practices to networking and IT with Cisco Certifications and DevNet

    News Summary:

    • Evolution of Cisco’s professional certification program embracesboth the network professional and now the software developer into one community to create the IT team of the future.
    • Cisco’s certification and training program now includes DevNet certifications and is designed for both the network professional and software developer to optimize and write applications for the new network and choose the technology skills they want to develop. 
    • Network automation is one of IT’s biggest challenges. The DevNet Automation Exchange provides shared code repositories which solve use cases for network automation and guides teams through their journey with a walk-run-fly methodology. Code is developed by the community and curated by Cisco as network automation best practices are developed by industry experts. 

    SAN DIEGO, California – Cisco Live U.S.- June 10, 2019 –Today Cisco is revolutionizing the role of network professionals and software developers to drive technology innovation and accelerate business. As Cisco reinvents the future of networking, DevNet (Cisco’s developer program) is bringing together software developers and certified network professionals into one community to enable unparalleled collaboration and best practice sharing and to pioneer new levels of automation capabilities. In addition, Cisco is introducing an industry-changing expansion of its professional certification program that embracesboth the network professional and software developer and adding a new community-based developer center to accelerate adoption and success with network automation.

    Cisco’s intent-based networking has led to a fundamental shift in the role networks play in business and changes how networking is done. The role of the networking professional has changed as it moves away from manual, time intensive tasks and into the world where IT, DevOps and application and cloud developers work together. To fully leverage the capabilities of this new network, organizations must leverage software practices, networking and software skills and an engaged community that solves technology challenges together.

    “Networking technology has evolved significantly over the last five years and the new network can accelerate business, catalyze new applications, and bring DevOps practices to networks,” said Susie Wee, SVP/CTO and founder of Cisco DevNet. “We are bringing software skills to the networking industry with new Cisco DevNet certifications. In addition, we are bringing software practices to networking by having a community of networkers and developers work together to solve tough network automation problems through shared code repositories. This will allow the industry to take full advantage of the capabilities of the new network to accelerate business.”

    BRINGING SOFTWARE PRACTICES TO NETWORKING: ACCELERATING NETWORK AUTOMATION WITH THE POWER OF COMMUNITY

    The network is the backbone of today’s digital business, but network automation remains one of the biggest challenges for IT. Cisco’s intent-based networking portfolio enables secure network automation at scale with a new community-based developer center called Cisco DevNet Automation Exchange. DevNet Automation Exchange features sharedcode repositories of use cases for network automation. Cisco’s community of developers, networking professionals, partners and customers can actively contribute software to create the industry leading repository for network automation code.

    DevNet Automation Exchange guides teams through their journey to implement network automation and intent-based networking with a Walk-Run-Fly methodology.

    • Walk: Get visibility and insights in their networks. This enables use cases such as gathering telemetry and insights from running networks, and performing auditing to ensure ongoing security of the network.
    • Run: Activate policy and intent across different network domains. This enables use cases such as providing self-service network operations that comply with security policies and operational guidelines.
    • Fly: Proactively manage applications, users, and devices with DevOps workflows. This enables use cases such as deploying applications in continuous integration and continuous delivery (CI/CD) pipelines while configuring the network in accordance with new application policies.

    DevNet Automation Exchange builds on the deep expertise of Cisco’s community of network experts and software developers, allowing them to collaborate and create automation best practices for their industries.

    BRINGING SOFTWARE SKILLS TO NETWORKING: NEW CISCO CERTIFICATIONS TO BUILD IT TEAMS OF THE FUTURE 

    A growing opportunity for innovation is applications that utilize a programmable network infrastructure to solve business challenges. However, in order to take advantage of this opportunity, partners and customers have to build teams with the appropriate software practices and networking background to optimize their networks and drive innovation.

    “With networking technology changing at an unprecedented pace, the world of infrastructure engineers and software developers must come together to build the IT team of the future,” said Mike Adams, Vice President of Cisco’s training and certification business. “For over 25 years, Cisco certifications has helped over 1.7 million network professionals around the world to launch their careers, demonstrate their technology capabilities and build a career path with the right skills to compete in the market. Now, the Cisco Certification program is designed so IT teams can optimize network and application performance, giving their businesses an edge in today’s dynamic digital world.”

    Cisco is evolving its certification and training program, with a focus on educating network engineers and now software developers to optimize the new network. The new training and certification program fast-tracks professionals to the knowledge they need to thrive in this new landscape under the key principles of leadership, agility and value. The new Cisco Certifications include:

    • New DevNet Certifications to validate software professionalswith DevNet Associate, DevNet Specialist, and DevNet Professional certifications. DevNet certifications are intended for software developers and network engineers who develop software proficiency to develop applications and automated workflows for operational networks and infrastructure.
    • Streamlined Cisco Certifications to validate engineering professionalswith Cisco Certified Network Associate (CCNA®) and Cisco Specialist certifications as well as Cisco Certified Network Professional (CCNP®) and Cisco Certified Internetwork Expert (CCIE®) certifications in enterprise, data center, service provider, security, and collaboration.
    • Expansion of Cisco Networking Academy offerings to train entry level network professionals and software developers.Courses prepare students to earn Cisco Certified Network Associate (CCNA®) and Certified DevNet Associate certifications, equipping them for high demand jobs in the IT industry.

    The new Cisco Certifications help organizations build teams with software expertise and infrastructure expertise to allow them to take full advantage of the capabilities of the new network to accelerate business. DevNet Automation Exchange brings a software-driven, community-based approach to building network automation solutions while leveraging the strength of Cisco’s community of networking professionals and software developers. Cisco Networking Academy will grow the workforce for Cisco’s partners and customers by training students to develop software and networking skills that leverage the new network.

    For all of the details on the certification and program changes, check out the Learning at Cisco featured page. For resources to get started with the DevNet certifications, check out the DevNet page.

    Availability: 

    • DevNet Automation Exchange is available now.
    • New courses will begin rolling out in June 2019 and exams will be available in February 2020. Learning materials applicable to the new DevNet certifications is available now on the DevNet developer site.
    • New certification exams will be available in February 2020.
    • For Cisco Networking Academy, updated CCNA® courses, assessments and tools will be available in English by November 2019, additional languages will follow the first half of 2020.

    Additional Resources

    About Cisco:

    Cisco (NASDAQ: CSCO) is the worldwide technology leader that has been making the internet work since 1984. Our people, products and partners help society securely connect and seize tomorrow’s digital opportunity today. Discover more at newsroom.cisco.com and follow us on Twitter at @Cisco.

    Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. A listing of Cisco’s trademarks can be found at www.cisco.com/go/trademarks.

    Some of the offerings and features described above remain in varying stages of development and will be offered on a when-and-if-available basis.  Any such items are subject to change at the sole discretion of Cisco, and Cisco will have no liability for delay in the delivery or failure to deliver any of the offerings or features set forth in this document.

  • Cisco announces its intent to Acquire Sentryo, the Pioneer of Cybersecurity Solutions For The Industrial IoT

    Lyon, France, June 7th – Cisco announced today its intention to acquire Sentryo. With organizations digitizing and connecting their industrial operations, the combination of Cisco network architecture and Sentryo capabilities of giving visibility into industrial control systems will help companies deploy Industrial IoT at scale, achieve new levels of flexibility, and better protect their assets and data.

    “We are very proud that the technology developed by Sentryo has been chosen by Cisco to become the cornerstone of the group’s IoT security offering. This is an important sign of recognition for the entire Sentryo team that we will continue to grow to offer the best technology enabling global organizations to ensure continuity, resilience and safety of their industrial operations.” said Thierry Rouquet and Laurent Hausermann, Sentryo’s co-Founders.

    More info: https://bit.ly/2QT2XCE

    About Sentryo
    Sentryo is the pioneer in solutions dedicated to managing the cyber risk of M2M networks and industrial control systems. Sentryo’s ICS CyberVision empowers operation engineers as the front line of defense to ensure integrity, continuity and security of their industrial processes. It leverages unique AI algorithms to give them comprehensive visibility on their industrial assets so they can easily identify vulnerabilities, detect anomalies in real time and work with IT to fight cyber-attacks. Sentryo’s ICS CyberVision is used every day by large corporations in the energy, manufacturing and transportation markets. Sentryo is headquartered in France and has a worldwide presence including offices and partners in Europe, North and South America, Middle-East and Asia. More info at www.sentryo.net

     

  • Cisco Opens IoT Development Center

    Cisco Opens IoT Development Center

    Cisco Systems this week launched an IoT Dev Center as part of an effort to foster development of a new generation of applications that will be deployed at the network edge.

    Announced at the Cisco Live EMEA event, the IoT Dev Center provides access to sandboxes and tutorials for building highly distributed IoT applications that Cisco envisions will be deployed directly on top of Cisco routers and switches. To facilitate that effort, Cisco also launched a series of ruggedized switches and routers, which, in addition to usingCisco ASICs for processing network traffic, can be configured to include x86 processors that enable low-latency applications to be deployed at the edge.

    The Cisco IoT Dev Center also provides access to a DevNet Ecosystem Exchange, through which organizations will be able to discover IoT applications optimized for Cisco infrastructure.

    Susie Wee, senior vice president for the DevNet community at Cisco, said the IoT Dev Center is an extension of the company’s ongoing efforts to build a DevOps community around Cisco infrastructure. From Cisco’s perspective, IoT represents an instance of edge computing.

    Cisco is attempting to extend its current dominance over networking infrastructure to include both networking gear for IoT environments and two-node hyperconverged infrastructure (HCI) platforms intended to be deployed at the network edge. Each of those systems will be connected via the Cisco Application-Centric Infrastructure (ACI) software-defined network (SDN), which Cisco says enables intent-based networking when infused with advanced analytics.

    Cisco claims it already has 40,000 customers using some element of its portfolio to drive an IoT application. As that ecosystem continues to evolve, Wee said it’s apparent that both operational technology (OT) teams, which historically have been responsible for embedded systems, and enterprise IT teams will need to embrace best DevOps practices to deploy, manage and update IoT applications. While embedded systems deployed by OT teams were not frequently updated, IoT applications will take advantage of containers and other microservices-based technologies to add new functionality more frequently and, when required, update systems to remediate potential vulnerabilities. By the end of the decade, many of those applications will be connected via 5G wireless networks that will provide enough bandwidth to make continuously updating edge applications much more practical than it is today.

    Less clear going forward is the degree to which networking teams will become part of a larger DevOps teams. As more applications get deployed on switches and routers at the edge, it’s obvious networking teams will play a critical role. The issue is to what degree. In many cases, networking teams will attempt to provide developers with access to a defined set of resources they can access via a self-service portal. But there are also likely to be instances when developers will want programmatic control over network resources that can be invoked via application programming interfaces (APIs).

    Naturally, Cisco is not the only networking vendor with similar edge computing ambitions. But while most IoT initiatives remain relative nascent, the next major battle for control over the network edge is more likely be determined by the sophistication of the processes enabled as it is the core underlying infrastructure.

    — Mike Vizard

  • Cisco Looks to Bridge Gap Between Networking and DevOps

    Cisco Looks to Bridge Gap Between Networking and DevOps

    Networking in the enterprise has always stood apart. It might take two minutes or less to spin up a virtual machine, but it can take two weeks to set up the network connections. To help bridge some of the gaps between networking and the rest of the DevOps team, Cisco Systems this week unveiled a series of intelligent switches that promise to do just that.

    Via a Cisco intent-driven networking initiative, it soon will be possible to describe a business outcome that will be automatically enabled at the networking level, says Kiran Ghodgaonkar, senior marketing manager for Cisco. To achieve that goal, Cisco is moving to unify networking on an end-to-end basis, which Ghodgaonkar says primarily will require building a common controller that can be implemented at both the edge of the network and in the data center.

    The first concrete step in achieving that goal is a set of Catalyst 9000 switches running an IOS XE operating system, which Cisco has imbued with machine learning algorithms. Over time, those algorithms will be deployed across both legacy networking infrastructures when appropriate, as well as any new networking and security equipment Cisco brings to market in the future. Once in place, IOS XE will make it easier to implement policies in software that spans everything from prioritizing traffic to implementing security polices.

    This latest Cisco initiative follows the rollout a Tetration analytics platform based on an instance of Apache Spark and Cisco’s acquisition of AppDynamics, provider of an application performance management service delivered via the cloud. Ghodgaonkar says Cisco is aiming to combine analytics and machine learning algorithms to simplify network management in a way that furthers DevOps integration. Right now, however, the biggest impedance to achieving that goal, says Ghodgaonkar, is the fact that 80 percent to 90 percent of networking tasks still require manual intervention. Because of that issue alone, many organizations have experienced limited success in terms of integrating server, storage and networking management, despite the rise of software-defined networking (SDN) in the data center. In fact, to get past that issue, many organizations make investments in pre-integrated systems such as the Cisco Unified Computing System (UCS) platform. But the number of organizations willing to make that kind in forklift investment in IT infrastructure is not all that high when compared to the size of the overall IT market.

    The biggest DevOps issue IT organizations now face, says Ghodgaonkar, is that as various elements of the IT organization invest in automation, silos of automation are created. Cisco says it has developed open application programming interfaces (API) will provide interoperability between its technologies and the rest of the IT environment to help break down those silos.

    It’s still a little unclear these days just how much networking and IT operations can get automated. The good news is that, given the state of network management inside most organizations, things can only improve. The real issue (as any existing DevOps team already knows) may not be so much the technology as it is the culture differences spanning the compute, storage and networking teams.

    — Mike Vizard

  • DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

    DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

    Puppet made three major announcements today around new versions of their flagship products, new products independent of Puppet Enterprise and a major expansion of partner programs and offices in the face of record growth over the last 12 months. As I detailed in my article on these announcements, these 3 taken together paint a clear picture of a market leader solidifying its position as an enterprise DevOps solutions provider. I had a chance to speak with Michael Olson of the Puppet product team about what these announcements mean.

    As usual, the streaming media player of our conversation is below. The transcript of our conversation follows immediately below (transcript will be updated shortly)

    Streaming Media

    Transcript of our Conversation

    Alan Shimel:                Hello everyone. This is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here on another DevOps Chat. Very happy to be joined on this episode of DevOps Chat by Michael Olson from the Puppet Product Team. Michael, welcome to DevOps Chat.

    Michael Olson:           Thanks Alan. Thanks for having me. Good to be here.

    Alan Shimel:                Pleasure. Pleasure to have you here Michael we always – actually we’ve had more than several people from Puppet over the years appear on DevOps Chat and we always – that’s always a great conversation.

    But today Michael you’re on here regarding several news announcements that Puppet put out recently today on May 11 and wanted to kind of go over them with you and cue our audience in to what I think are several major announcements coming kind of down the pike from Puppet.

    So if it’s okay with you Michael, you know the news as well as I do, do you want to lead off with what you think is the most important one or do you want me to pick?

    Michael Olson:           Sure, I’m happy to dig in. And today’s been certainly a pretty big day at Puppet, we’re pretty excited to announce a very significant set of investments that we think really continues to deliver on our mission of empowering IT to deliver better software faster, so looking forward to digging in to what that entails.

    It’s really around new products that help IT manage the complexities of their evolving and modern infrastructure as well as updates to some of our existing products that give really IT better control and situational awareness for the software that they deliver and run.

    And then new partnerships and company investments that are really focused on ensuring that Puppet is where our customers need us to be, that our customers and our community and ecosystem really have the talents and the support needed to scale their success wherever they are, so looking forward to digging into it with you.

    Alan Shimel:                Okay. So if you don’t mind Michael I’d like to start off with the announcements around new products – Puppet Cloud Discover – and if I mispronounce it I apologize – Lumigon? Is that how you pronounce it?

    Michael Olson:           Alan, you nailed it. Well done.

    Alan Shimel:                Okay. Well every once in a while even a blind squirrel finds a nut. But anyway, so we have Puppet Cloud Discover and Lumigon – and these are offerings in the container and cloud native technology areas, but beyond that Michael why don’t we dig in a little bit. What exactly is Cloud Discovery first?

    Michael Olson:           Sure. And you’re exactly right. And I think before we dig in it’s useful just to set a little bit of context Alan and I’ll start by saying that our heritage really at Puppet has been rooted in helping IT professionals cope with sort of the complexity of managing an ever-growing infrastructure and application estate really by kind of harnessing automation.

    So for more than a decade our core focus has really been around helping our customers define a desired state model for their infrastructure and applications and then providing an engine that translates that desired state of how they want their infrastructure and applications to look into reality.

    So that has benefits of doing things like preventing configuration drift and eliminating manual intervention from the software delivery process.

    And one of the things that we’ve seen is – you know, over the course of this journey over the past 12 years is we’ve been very fortunate to be supported by a passionate open-source community that’s helped refine our offerings, coving every aspect of systems management so that our new users that are getting onboard with Puppet can hit the ground running so to speak as opposed to having to start from scratch.

    And so in light of that we are making investments to better support that journey for our customers and answering some of the common questions that we’re hearing from them. Things like, “How do we get started with automation and modeling?”

    And one of the most common starting points that we see our customers looking to solve for is just know what software they have running across their datacenter and their cloud and container environments: answering a simple question of, “What resources and applications do I have running today? How do I bring those resources under management?” And I kind of refer to that general category of problems as discovery

    So what we’re announcing today is really a new set of investments and offerings that are intended to give IT teams much better situational awareness into what they have running across their application and infrastructure estate regardless of whether that’s running in the cloud, in containers or on their traditional on-premise datacenter.

    Alan Shimel:                Got it. Got it. So Michael I think that kind of explains a little bit what Cloud Discover is – Puppet Cloud Discover. And I’m looking at these two names of Cloud Discover and Lumigon – I’m reminded back to my days at one of the security companies I helped co-found – Still Secure – but we always had this sort of battle between descriptive names or kind of catchy marketing type of names.

    And when I look at Puppet Cloud Discover that’s certainly a descriptive name, right? I think you almost get what it is from the title and it obviously fills a real need in the market as we get these – I guess you call it cloud sprawl – of an ever-expanding infrastructure and understanding what we’ve got there.

    Talk to me a little bit about the other one though, Lumigon. How did we come up with that name and what does it do?

    Michael Olson:           You bet. Yeah, Lumigon is a new offering from Puppet. It’s open-source so it’s something that is available for our community as well as anyone who is responsible for managing containerized environments within their organizations to go to our website and just simply pull down and start using today.

    And I think as we all know containers have really emerged as a new and common way of packaging applications with that container image being the artifact that’s handed off from development into operations, and we think containers represent a really big opportunity for orgs that want to accelerate their product delivery.

    But today what we’re often hearing is that those container environments are largely black boxes from an operational standpoint. What’s more, since there’s so many of them, containers tend to be ephemeral, so to speak, they tend to have shorter lifespans than VMs and that brings a whole set of challenges where you’re looking at bringing containers into production environments.

    So what we’ve announced today is a new offering. It’s open-source and free and available for anyone to go and pull down and start using of Lumigon which is an offering that really focuses on discovering what’s running inside all of those container environments and giving operators really better visibility and control around their container estate.

    So because this Lumigon effort is an open-source tool that can analyze applications – you know, we’re initially targeting docker containers and exposing application metadata about those but certainly looking at extending that over time as we continue to get feedback from the community.

    Alan Shimel:                Great. Now Michael over the years we’ve spoken to several Puppet people – among them Gareth Rushgrove, D-Pack, Sonja himself – and we’ve talked here at devopsy.kinsta.cloud about Project Blue Shift at Puppet which is kind of, as you probably are well-aware – Puppet looking at new technologies and making sure that they – that Puppet’s mission encompasses working with these new technologies.

    Is Lumigon something that maybe comes out of Project Blue Shift or independent of that?

    Michael Olson:           I think it really represents a common vision from Puppet which is you know we see a lot of organizations in our customers that are really looking to automation as a bridge to their future. As organizations look to modernize physical infrastructure and move it into the cloud, adopt containers in production environments they’re looking to have automation really baked in from day zero as they look to do that.

    And so Blue Shift is, as we’ve talked about in the past, really represents Puppet’s vision for helping our customers adopt the cloud and containers in consistent, repeatable and reliable ways. So it encompasses things like using automation to install docker or lay down operating environments in docker, for example, as well as do things like define and deploy the services that run inside of docker containers giving our customers really better portability to be able to kind of lift and shift workloads that they may have defined and are running on virtual infrastructure, for example, and getting that running in containers without having to adopt platform-specific tooling to do so.

    Alan Shimel:                Make sense. And certainly – I mean I’m fresh out of Docker Con two weeks ago now – it seems like two weeks – maybe it was last week – but in any event I mean the shift to a containerized application infrastructure is well underway and so a product such as this obviously I think should find a ready market and the fact that it is an open-source tool and everyone can get involved.

                                        Michael what is – or other – I know it’s early in the game but are there any plans to have an Enterprise or pay-for version of Lumigon out there?

    Michael Olson:           You know it’s certainly something that we’re looking at longer-term is as we continue to build off of this foundation, you know, ensuring that we’re meeting the needs of our large Enterprise customers as well as the broad community of more than 36,000 organizations that rely on Puppet technology today to deliver and operate their software

    And I think what we’re focused on right now is really making sure that we’re nailing that core set of problems with a sledge hammer which is, “How do I expose the black box and know what’s running inside of my container environments so I can do things like identify if I’m vulnerable to a potential CVE or if I’m vulnerable to a bug in a library dependency. You know, to know if for example my OS standards are being followed and adhered to within my organization.” These are the types of questions that Lumigon will help users answer today.

    And then shifting to the Cloud Discovery announcement that we talked about briefly earlier we’re also introducing a new offering here at Puppet that’s really focused on giving IT teams better situational awareness into what’s running in their cloud infrastructure specifically in AWS.

    And so it’s really focused on helping IT teams go back and discover all of the resources and applications that are running in AWS. This is a limited preview that we’re offering for Cloud Discover today really to give those teams a better sense of what they have running in the cloud so they can make better decisions about how they want to bring them under management through automation.

    Alan Shimel:                Great. So Michael both the Cloud Discover and Lumigon in some ways are maybe the cabooses on the engine here with the announcement of a new version of Puppet Enterprise – or at least the availability of a new version of Puppet Enterprise.

    Why don’t you tell our audience a little bit about that?

    Michael Olson:           Sure, yeah. So Puppet Enterprise – we’ve introduced a new version, we call it 2017.2 per our naming conventions – and I’ve been at Puppet for a few years now and in my opinion it’s really not an exaggeration to say that it’s one of the more significant releases that we’ve had in several years, really with a focus on giving our customers better visibility into the software that they have running on premise in their datacenter no matter how they’re managing it, as well as easier, simpler tools to be able to orchestrate deployments and run deployments across infrastructure and applications using visual workflows.

    So the first set of innovation that we’ve introduced into the latest version of Puppet Enterprise is really around being able to inspect software packages that are running across your datacenter.

    And one of the areas of feedback that we frequently hear from IT teams is it’s hard to know what software packages are running across their infrastructure, what versions they’re running, for example, in order to easily identify packages that may be vulnerable to security risks.

    So we’re introducing some new reporting for our Puppet Enterprise customers in this version that’s really focused on giving IT easy visibility into the software packages that they’re running regardless of whether they’re being managed today by Puppet in order to really provide that insight to identify potential security issues a lot faster

    And then as our customers look to use automation in order to drive change across their software stack we’ve also introduced a whole set of orchestration capabilities over the course of the past year-and-a-half. With this release we’re extending that to the Puppet Enterprise Web UI essentially giving our customers the ability to define, run and monitor deployment jobs entirely using visual workflows within the Puppet Enterprise Web UI.

    So it’s easy to do things like define a deployment job, target a specific portion of your infrastructure, run a phase deployment for doing things like canary workflows, and then monitor the status of that deployment in real-time so if things aren’t going well you can hit the stop button, investigate, tinker as needed and then restart that deployment; so giving our customers a lot more flexibility into how they drive change across their software.

    Alan Shimel:                Fantastic. And I love the naming conventions here – I remember speaking earlier about it – I think it makes it easy for people to see where they are and what they have – but the simple naming kind of hides the fact that there’s a lot more punch in here. And by the way, that’s available now Michael?

    Michael Olson:           Correct, it is. Yeah. It’s available today for – certainly for current Puppet Enterprise customers – and for anybody who’s new to Puppet out there you can simply go to our website and pull down a copy, it’s free to try on up to 10 different servers, devices or applications.

    Alan Shimel:                Sure. Michael, and I didn’t ask this – my apologies – for the Cloud Discovery and Lumigon – what’s their availability?

    Michael Olson:           Yeah, Lumigon, which is really around, again, kind of exposing the black boxes of containers, is – that offering is available to try today and you can find a way to get there directly from our website at Puppet.com. And then the Cloud Discovery offering is available as part of a limited preview so what we’re really looking to do is if you’re interested sign up through our website and we’ll be in contact with you if you’re interested to discuss next steps.

    Alan Shimel:                Perfect. Next Michael let’s talk a little bit about the last announcement today, and this one was more around sort of momentum – it looks like a bunch of new Enterprise customers added as well as new locations and partners and partner offerings. I don’t know if I left anything out but give us some of the details there if you can.

    Michael Olson:           Sure, yeah, happy to do so. And you know you get this Alan, obviously you and I have talked before, but what we’ve really seen over the course of the past several years is just a huge surge in growth and momentum for Puppet and I think it’s been fueled by growing demand in the market for dev-ops and for digital transformation.

    So we’re really taking that momentum and using it to grow more aggressively and really help our customers be more successful, you know, laying the foundation for dev-ops wherever they are in the world.

    So what we’ve also announced today is a new set of partnerships with organizations like AWS and Cisco and others as well as global expansion for Puppet: we’re opening up new offices in Singapore really to better serve the needs of our customers internationally and ensure that Puppet is with them wherever they are and however they want to engage with us.

    Alan Shimel:                That’s great. What about from a partnership point of view though? Any new partners to announce or just partner offerings?

    Michael Olson:           Yeah, from a partnership perspective – I’ll touch upon a couple things – one of which is we have a new marketplace offering up on AWS that we also made available today and really the key takeaway there is as our customers are increasingly looking to kind of recognize the value of cloud-based environments – they’re using AWS – we’ve really deepened our relationship with Amazon Web Services and deepened that partnership with a new offering that basically makes Puppet Enterprise available on the AWS marketplace on an hourly pay-as-you-go basis.

    So it’s really focused on simplifying the installation of Puppet Enterprise and providing a way of securing configuration and getting better visibility into your AWS infrastructure through Puppet directly from within the AWS marketplace.

    Alan Shimel:                Yeah. You know, to me Michael that’s a huge winner, right, because number one – I’m familiar with the AWS marketplace and there’s no lack of solutions up there – but once you’re in there and you have the ability to kind of piggyback the AWS billing, if you will, for hourly service and hourly offerings – it allows people to consume their services in the manner that they’re used to consuming them in AWS, right?

    I think early on there was a big rush to the AWS marketplace but if you weren’t truly integrated into AWS it just, you know, from a billing perspective and usage monitoring and all that, it – I think their customers just did it – it was just too clunky frankly, right? So this makes things a lot smoother in you’re an AWS customer.

    Michael Olson:           I think that’s spot on Alan. Like the constant feedback that we hear from our customers is they want us to meet their needs and engage them how they want to be engaged, so to speak, and I think this is a marker that helps payoff that objective that customers have is, you know, if you’re looking to bring automation into your cloud environments – you know, looking to get started for the first time – just, you know, click a few buttons and spin up Puppet directly through the AWS marketplace.

    And we’ve also really extended our partnership with Cisco in some of the partner-related announcements that came out today as well as we see more Cisco customers that want the power of Puppet as a way of defining, deploying and operating all of their software. So with our expanded partnership joint customers of Puppet and Cisco can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco value-added reseller.

    Alan Shimel:                Cool. Very cool. Okay. Michael, you know, I promised you we were going to do 15 minutes and here we are for over 20 – I apologize – but before we wrap things up did we miss anything in the announcements?

    Michael Olson:           I don’t think so Alan, this has been a great conversation and I think we touched upon most of the highlights.

    Alan Shimel:                Yeah, I think so too. You know not everything fits into a 15-minute bucket though in life so I apologize but I think it was well worth the time spent digging into these new, exciting developments and announcements over at Puppet.

    Michael Olson from the Product Team at Puppet thanks for being this episode’s guest on DevOps Chat. Hope to have you on again soon.

    Michael Olson:           Likewise. Thanks for having us Alan and it’s always great to catch up with you.

    Alan Shimel:                All righty. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening everyone and we’ll see you on another DevOps Chat hopefully very soon.

    — Alan Shimel

  • Puppet Solidifies Enterprise Provider Status With Bevy Of Announcements

    Puppet Solidifies Enterprise Provider Status With Bevy Of Announcements

    Puppet has been maturing from a company with an enthusiastic base of users of an open source tool, to a leading provider of enterprise DevOps solutions for the last few years. Things really accelerated with the appointment last year of Sanjay Mirchandani, as CEO and the group of experienced, A+ players he brought to the executive team. Today Puppet took another step towards solidifying their position as a leading provider of enterprise DevOps solutions with a string of news announcements highlighting new products, accelerated growth and new/expanded presence.

    Lets start with what for many of you will be the most important. Puppet today announced “the general availability of Puppet Enterprise 2017.2, and upcoming availability of Puppet 5 Platform, the latest version of Open Source Puppet.” I had a chance to chat with Puppet CTO Deepak Giridharagopal, Chief Product Officer, Omri Gazitt and VP of Marketing, Tim Zonca. In their considered opinion this new version of Puppet Enterprise, more than just another upgrade, may in fact be the most significant upgrade to Puppet ever.

    From the press release, the most significant of these new capabilities are:

    • Package inspection: Users get started with automation by quickly identifying packages that aren’t being automatically managed, but should be. With package inspection, Puppet Enterprise users report on unmanaged infrastructure, making it easy to see the systems that would benefit most from automation to ensure their most critical software has the right maintenance updates, security patches and licenses.
    • Visual orchestration workflows: Users orchestrate infrastructure and application deployments entirely from within the Puppet Enterprise web UI, without writing a single line of Puppet code. Enterprises can target specific infrastructure environments using drop-down menus and filters, define workflows, monitor deployment status in real-time, and start, stop or restart deployments as needed, all with the click of a button.

    Both of these are much deeper than the few words from the press release. In addition to these though, there are also even more new capabilities packed in to 2017.2. Additionally, the open source Puppet platform 5 has many new innovations and hooks that will continue to keep the large base of open Puppet users happy, if they don’t require or need the greater feature set of the enterprise version.

    Speaking of those many users, that is the lead in to the second announcement. Puppet is growing and growing fast. Over the last 12 months they have added more than 250 enterprise customers to the business. Today over 37,000 companies use Puppet, with over 75 of the Fortune 100 also relying on Puppet. To help satisfy this increasing demand, Puppet announced the opening of a new Asia-Pacific office in Singapore, a large expansion of their existing office in Sydney and the opening of a new R&D center in Seattle.

    Puppet also announced significant additions to its partner program and participants:

    • New AWS Marketplace offering: As enterprises continue to recognize the value of cloud-based environments, they are turning to AWS and other cloud platforms for efficiency, savings and scalability. To support cloud efforts, AWS and Puppet deepened their partnership, making Puppet Enterprise available on an hourly, pay-as-you-go basis. The new offering simplifies installation, provides secure configuration and delivers immediate ROI.
    • Extended Cisco partnership: As software defined networking continues to evolve as a key tenet of the modern data center, Cisco customers want the power of Puppet Enterprise as a unified way of defining, deploying and operating all the software they run. Joint customers can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco VAR.
    • New partners for security and DevOps: Puppet has added a number of important partners as part of its inaugural class to the Technology Alliance Partner Program (TAPP). By collaborating with F5, Splunk, Cumulus Networks, CloudPassage, Conjur, CyberArk, Onyx Point, Intelliment and Sensu, Puppet and its partners collectively deliver a better architecture around security and DevOps.

    Again, all signs point to Puppet’s ascendence to enterprise provider status as it matures into its market leader position.

    The third and final announcement from Puppet is by no means the least of the three. In addition to the first two announcements, Puppet also announced two new offerings, Lumogon™ and Puppet Cloud Discovery™. With these the company expands its enterprise offerings beyond Puppet Enterprise, empowering companies to overcome challenges associated with modernizing infrastructure and application stacks.

    These are first offerings independent of Puppet Enterprise offered by the company. The represent significant new capabilities in two quickly growing markets, cloud and containers.

    Lumogon empowers “anyone involved in running containers, like site reliability engineers (SREs), release engineers, DevOps engineers, and the application developers themselves, now have a tool to gain operational insights into what makes up their containers with Lumogon. Lumogon provides a transparent window into each Docker image and running container, and offers a way to collect, query and report on container application metadata.”

    “Puppet Cloud Discovery collects and visualizes a rich set of system data to give users better awareness of the state of their infrastructure. Unlike other tools on the market that were built for traditional on-premise infrastructure, Puppet Cloud Discovery is cloud-first and is designed to model ephemeral cloud infrastructure. Puppet Cloud Discovery is delivered as a service, making it easy for users to see immediate time-to-value.”

    So Puppet has raised the bar and solidified its position in the marketplace. When taken together these three announcements illustrate that Puppet is accelerating in almost every facet. It will be interesting to see how they continue to build in the months and years to come.

    — Alan Shimel

  • Cisco and Docker Team to Modernize Cloud and Data Center Application Environments

    SAN JOSE, Calif.—March 2, 2017—Today, Cisco (NASDAQ: CSCO) and Docker Inc. announced a strategic alliance for worldwide engineering, sales and support to deliver essential container capabilities for application-centric data center and cloud infrastructure.

    Customers can modernize applications using Docker Enterprise Edition (EE) with Docker Datacenter, and deliver them securely and efficiently across Cisco Unified Computing System (UCS) and Cisco validated Converged Infrastructure solutions with Cisco partners.  Cisco and Docker will deliver unified and certified solutions for the entire application journey, whether organizations are containerizing traditional applications, refactoring applications to microservices, or creating new applications.  Docker EE with Docker Datacenter running on Cisco UCS will provide application developers a seamless way to deploy, iterate, re-deploy, and monitor applications onto production infrastructure.

    This worldwide initiative between two industry leaders will deliver:

    • Reduced complexity for improved manageability and automation, leveraging the unified, highly scalable architecture of Cisco UCS, with consistent management across all computing environments – traditional and modern.  Cisco UCS is ideal for distributed, microservices application architectures with high performance networking and comprehensive infrastructure controls via application programming interfaces.
    • Scalable, resilient, secure networking for containerized applications using Contiv, a Cisco-initiated open source project that allows IT organizations to implement comprehensive network policy enforcement.

    “The powerful combination of Cisco’s leading UCS product line for Cloud infrastructure and Docker’s containerized technology will offer customers high levels of security, manageability and scale,” said Liz Centoni, Senior Vice President and General Manager, Cisco Computing Systems Product Group. “Developers and IT, working together, can now build, ship, and deploy container applications anywhere.”

    “Enterprises are increasingly looking to Docker to modernize their traditional applications so their investment in Linux and Windows Server applications can achieve major operational efficiencies while making these applications more agile, cloud-ready and more secure” said Ben Golub, CEO, Docker. “This strategic partnership brings even more opportunity for these enterprises by running Dockerized applications on a validated Cisco UCS infrastructure that is optimized for security, availability, performance and scale.”

    Docker EE is the leading container platform for enterprise developers and IT teams that are looking to converge a diverse set of application pipelines under one uniform packaging format, API & tooling for all their applications across the entire application lifecycle. Docker EE establishes the foundation for a Containers as a Service (CaaS) model that becomes the framework for an enterprise software supply chain where any applications (traditional and microservices) can be managed centrally and uniformly across any infrastructure.

    Joint sales and support programs across Docker, Cisco and Cisco channel partners ensure that Docker EE works seamlessly for applications deployed across hybrid cloud, converged infrastructure, converged storage, hyperconverged infrastructure, and Cisco servers. Enterprise customers have the assurance of Cisco-supported Docker platform as part of this strategic relationship.

    Cisco and Docker plan to deliver joint solutions, which will be available through Cisco’s partner channels with full support:

    • Contiv: Contiv is a Cisco-sponsored, completely open source networking fabric for heterogeneous Docker deployments across virtual machines, bare-metal, and public or private clouds. As the industry’s most powerful container networking fabric, Contiv, with its Layer2, Layer3, overlay and ACI modes, natively integrates with Cisco infrastructure and complements Docker by directly mapping the application intent with the infrastructure capabilities using rich networking and security policies. At Cisco Live! Berlin 2017, Cisco announced the availability of Contiv 1.0.  Cisco and Docker announced today that Contiv is now a Docker Certified plugin, through participation in the Docker Certification Program, a framework for partners to integrate and certify their technology to the Docker Enterprise Edition commercial platform.  Contiv is available as a certified plugin in the Docker Store.
    • Cisco Validated Design (CVD) for Docker Data Center on Cisco UCS: Customers can quickly deploy Docker Datacenter in a development or production environment on Cisco UCS B-Series blade servers or C-Series rack servers by leveraging a certified reference architecture and best practices for deployment.  This solution is targeted at stateless container deployments and comes with entry and mid-range configurations; it is ideal for customers who want to jump start their container journey.
    • Cisco Validated Design (CVD) for Docker Data Center on Converged Infrastructure:  Cisco, a leader in the converged infrastructure market, brings its proven data center architecture to containerized deployments through its CVD “Flexpod with Docker Data Center for Container Management.” This CVD delivers a highly available and scalable converged infrastructure solution including how to deploy and configure Docker Datacenter on FlexPod to utilize both virtual and bare-metal instances of Docker Universal Control Plane (UCP) nodes. The reference architecture also includes manual deployment and automated deployment processes for Cisco UCS and the Docker volume plugin for NetApp storage.

    Cisco has a proven history of working with partners to develop solutions that deliver business value. The Cisco Unified Computing System (Cisco UCS™) and Cisco Application Centric Infrastructure (Cisco ACI™) are open infrastructure frameworks supported by broad, mature partner ecosystem. The alliance with Docker will extend benefits of Cisco’s data center architectures to container environments, and the two companies will collaborate going forward to bring additional solutions to the marketplace.

    Availability

    Contiv is available now at http://contiv.io and can be downloaded from Docker Store and GitHub

     Cisco Validated Design (CVD) for Docker Data Center is available now.

    The Cisco Validated Design (CVD) for Converged Infrastructure is available now.

    Additional Resources

    Learn more about: Cisco Data Center and Virtualization

    Learn more about: Cisco Unified Computing System

    Learn more about: Cisco Data Center Services

    Learn more about:  Contiv

    Read Cisco Contiv blog: Contiv 1.0

    — Jules Louis

  • What Cisco’s OpFlex means for DevOps

    What Cisco’s OpFlex means for DevOps

    Some big news in networking land at Interop this year revolved around Cisco’s latest contribution to open source and the Internet, its proposed “OpFlex” control plane protocol.

    The protocol itself is focused on communicating with network elements and specifies encoding in a variety of formats, including JSON, that are developer-friendly. That’s nice, of course, but the big question as someone interested in operations and devOps is why should you care about what appears to be a networking protocol? After all, beauty is only interface deep. What’s in it for you?

    To see where DevOps fits into the picture, consider the description of OpFlex as specified in the IETF draft of the OpFlex protocol:

    The OpFlex architecture provides a distributed control system based on a declarative policy information model. The policies are defined at a logically centralized policy repository (PR) and enforced within a set of distributed policy elements (PE). The PR communicates with the subordinate PEs using the OpFlex Control protocol. This protocol allows for bidirectional communication of policy, events, statistics, and faults. This document defines the OpFlex Control Protocol.  [emphasis mine]

    What’s being offered is not just a protocol for bidirectional communication, but an entire architecture for sharing policies and actionable data. What’s more important to those who for whom “networking” is not their native technical tongue is that policies are designed to be declarative and abstract. That means instead of issuing a set of commands, often specific to the device or service, a policy declares (describes) what’s needed and each component participating in the architecture interprets those needs according to their specific function and capabilities.

    You might be thinking at this point (I know I certainly was) “What is this policy and who is defining it?” because that seems pretty central to the value proposition of this whole endeavor.

    For that, we need to look to the OpenDaylight (ODL) project which has created a new project called the ODL Group Policy plug-in. As explained by Cisco in an OpFlex white paper, “the goal of this project is to provide a policy-based API that can serve, in practice, as a standard information model in OpFlex implementations.”

    Jumping over to the ODL Group Policy Plug In wiki, then, the intention of the Group Policy Plugin is to introduce “the notion of groups of endpoints and policy abstractions that govern communication between these groups. The goal is to support a northbound API that accepts abstract policy based on application requirements while offering numerous concrete southbound implementations for programming network element with configuration/programming stanzas rendered from application policies.”

    Okay, so that’s a whole lot of .. words. What it boils down to is that instead of a policy describing a set of rules governing routing with the appropriate ACLs, one might simply declare that “Web Server A can talk to Database Server A to perform database transactions” while “Administrative Console B can talk to Database Server A about administrative tasks.” If you were to translate that into specifics you would likely have multiple imperative command lines, each describing VLAN participation and routing  as well as entries allowing traffic between specific VLANs or IP addresses on the ports appropriate to the application layer protocols. It would be long and prone to misconfiguration simply due to the number of commands required. Using a declarative (abstract) policy language simplifies not only the policy but also addresses the disparity inherent in competing products across a given market by eliminating it from being problematic.

    The problem with traditional proposals to solve the “different definitions and object models” across a given market space (like ADCs or IPSs or switches) is that they’ve all relied on finding the lowest common model, which inevitably ended up with all offerings needing to dumb down (commoditize) their value in order to ensure consistent support for all “XYZs”. By abstracting to the policy – and not the object model – level, the OpFlex approach effectively eliminates this issue and emphasizes defining what is desired by the application, but not how.

    Now, the actual policy declaration is unlikely to take the form of natural language (that’d be nice, but we’re not quite ready for that… yet, though Watson might disagree with me on that) but the general premise is to provide a far more, shall we say, friendly policy language.

    What this means is the operations folks most likely to be familiar with the application architecture and who understand what it needs and how it needs to work, could be the ones to actually codify that into policies. You’ll note that the intention for OpenDaylight, at least, is to “support a northbound API that accepts abstract policy based on application requirements.” That means someone – hint, hint, that’s you – might be able to integrate into the application deployment lifecycle provisioning of the network services and topological constraints required based on an understanding of the complex web of connections between each piece of an application. Someone who knows from experience that a “three tier architecture” means more than just three components, and can more effectively describe how they should be interacting.

    But that’s just the beginning. You’ll note that in the RFC summary above it specifies “bidirectional communication of policy, events, statistics, and faults.” That means actionable data is being exchanged between participating components. Actionable data enables, well, action. Actions that might address a fault that occurs between end-points. Actions that might address performance issues. Actions that might mitigate attacks in real-time.

    Ultimately this level of capability will drive new solutions – new workflows and processes – that take advantage of event-based systems and policy-driven networking. OpFlex should enable statements like “When X happens, do Y” to be executed upon, even if it requires coordination of three or four or more network components.

    What OpFlex means for the devops practitioner is a way to influence (or, one hopes, specify directly) what services the network provide for the applications you’re tasked with deploying and delivering, and how the network responds to the things that happen on any network that impact the performance, security or stability of those applications.

    As networking continues to recognize and address the need to provide application-driven services, including provisioning and real-time adaptation, it’s going to continue to become more programmable and integrated with the systems driving a more automated, orchestrated data center. And that means devops practitioners are going to have more and more options as to how they manage the entire application (and network) service lifecycle.

  • Google Starts Cloud World War I, DevOps Wins

    Google Starts Cloud World War I, DevOps Wins

    No matter the outcome, a cloud pricing war will leave DevOps the winner

    By now you probably saw the news and all of the buzz about how Google dropped its drawers eh, pricing on its cloud hosting. This is of course a direct shot at Amazon’s AWS. It’s about time someone with big enough stones (and a big enough data center) took on Bezos and his band of merry cloud makers.  But the real winner in all of this may in fact turn out to be DevOps.

    Of course this is just the first salvo in what promises to go down in history as Cloud War I. Amazon is not going to stand still.  They are perfectly willing to compete on price and in fact part of the AWS mystique is that it is the most cost effective solution (cheapest) out there.

    This will not be just a tit-for-tat move though. In announcing the price cuts Urs Hölzle, VP of TI at Google said, “”We think cloud pricing should track Moore’s Law, so we’re simplifying and reducing prices for our various on-demand, pay-as-you-go services by 30 to 85 percent.”  That means we are going to see cloud prices drop as the speed and power of chips goes up. That is good news! You can see Hölzle’s complete presentation including a cameo by SnapChat’s Bobby Murphy below (be warned this is about 1 hour and 20 minutes long).

    [youtube=http://www.youtube.com/watch?v=qokEYBNWA_0]

    Of course this begs the question, what about the other cloud providers.  How long can Rackspace sit up on its OpenStack perch before diving into this fray? What about Microsoft’s Azure? Redmond wants its piece of the cloud pie, does new CEO Satya Nadella have the stomach for this fight? Can they afford not to? The fact is that Microsoft has the girth and arsenal to compete here. Maybe Google starting this war is the opening they need to climb out of the tech cellar and be relevant again. Cisco just announced a billion dollar initiative to become a cloud powerhouse as well.  As big as a billion is though, that is penny stakes in this game I am afraid.

    Here is another one to watch, IBM’s SoftLayer. Fresh off of a 2b+ acquisition and pledging another billion in cloud dollars, IBM via SoftLayer has the profile to be a winner in this war as well.  They also have IBM’s minions out pushing the solutions. In fact Microsoft and SoftLayer/IBM may have the channels to win this thing in the long run (OK maybe not).

    So where does this leave DevOps? Think Switzerland.  From a DevOps perspective it really doesn’t make a difference which cloud provider emerges dominant. The cheaper and more attractive cloud becomes the more it will drive better DevOps tools, DevOps culture and philosophy.

    Of course there are those that say that if PaaS becomes the dominant cloud platform (and I think it will), that could spell trouble for DevOps.  As if somehow PaaS doesn’t need DevOps.  I say poppycock to that too. Maybe you won’t configure servers in a PaaS environment (and I am not conceding that either), but there will be plenty of places along path that will call for automation, continuous delivery, continuous monitoring and continuous management.  PaaS does not obliviate DevOps.

    That is not to say that applications are not king.  Applications are driving the cloud, DevOps and everything else tech today. A large reason why Google is so goo-goo over Cloud is because it drives more Android apps.  I think we will see more DevOps tools and practice around application development, configuration, management and monitoring. New Relic is already on it.  Anything related to Docker stands to do as well as munition and tank manufacturers did during WW II.

    So buckle in as it may get rough out there as these tech giants battle for cloud supremacy, there an will be winners and there will be losers.  It won’t be just the cloud providers either.  Wars create opportunity and those willing to take the chance will gain the most.

    But for DevOps it is all good. It is like we have a stash of chocolate and gold while we make watches here in Geneva. The war rages on around us but we need at the end of the day no matter what we win.