Category: Infrastructure/Networking

  • Why the Built World Needs Standard APIs

    Why the Built World Needs Standard APIs

    Lately, new ESG initiatives have come front-and-center as companies seek to contextualize and limit their business’s impact on the environment. This is especially true for the built world—a term that refers to the human-made environment that provides the setting for human activity, including homes, buildings, zoning, streets, sidewalks, open spaces, transportation options and more—where monitoring energy efficiencies is becoming more commonplace and even required by law. For example, a New York City law now requires buildings of a certain size to post an energy-efficiency score at their entrances. Yet, calculating such a score isn’t that straightforward—there’s a lot of legacy technology in use within most large commercial and residential buildings, and pulling data from these systems is notoriously difficult.

    A building manager may seek greater visibility into these systems to not only determine a building’s energy score, but to program optimizations, inform building security or enact new digitization. But the answer isn’t to hastily rip out and upgrade old hardware—old equipment like AC units and elevators were built to last 50 years or more and could be functioning seamlessly. Instead, this is another area where REST APIs are set to accelerate by uniting legacy integration software and disparate hardware with a standard layer.

    I recently met with Shaun Cooley, CEO and founder of Mapped. According to Cooley, API-driven standards for built environments could open up transparency into hardware component behaviors and the interrelationships between systems within a building. Below, we’ll briefly consider the history of building protocols and look to standards like Brick Schema that aim to unite legacy and modern physical infrastructure. We’ll consider the competitive advantage APIs bring to the built world and how increasing data accessibility could assist operations.

    The State of Physical Building Digital Protocols

    The built world consists of various digital communications standards. Most buildings have many older on-premises protocols for lighting, HVAC, elevators and other systems. For example, many elevators and fire safety systems were installed by systems integrators in the 1970s and adopted connections using Modbus, a communication protocol based on serial connections. BACnet is also commonly used to control HVAC systems and is a step forward from Modbus in that it can more easily connect to IP networks.

    Fast-forward a few decades to the dawn of the cloud; many companies overlaid sensors onto these old systems, explained Cooley. These power-over-ethernet (PoE) or battery-powered systems relay data immediately to the cloud and often speak in proprietary protocols. A single commercial building could easily be juggling a bundle of these various communication protocols, all originating from installations that occurred at different time periods. These nuances mean that you are “constantly dealing with chaos across your portfolio,” Cooley said. There’s so much data, but getting it normalized and usable is very challenging, he said. One must integrate with many sensors and protocols, which he describes as “the dirty plumbing” that no one wants to build.

    There’s bound to be differentiation from building to building, too, which could place a further strain on managing multiple building operations. Without a window into building data, it isn’t easy to know things like the current occupancy of the lobby or how occupancy affects energy consumption. Unless managers can connect the dots between systems, it’s impossible to understand the relationships between components.

    Making a Data Graph for a Building

    For example, take an AC system in a commercial building. Such a unit isn’t as simple as a single-family home’s typical thermostat and furnace. It’s often a mix of a rooftop chilling unit, pipes, pumps and a VAV damper that controls the air. While protocols are good at describing how individual components are performing, the composition of components is really what defines a building’s system and its efficiency, said Cooley.

    According to Cooley, instead of adopting a vertical data schema, buildings require a graph data model to adequately represent hardware interconnections. This is why he’s rallying behind Brick Schema, an open source uniform metadata schema for buildings. Instead of a vertical data schema, Brick Schema is built on a graph data model, which enables more descriptive relationships in a system.

    End Benefits

    Pulling unstructured data from 20 different data lakes into a clean API could allow easier access to new solutions. “We want to make it very simple to build applications for these sorts of environments,” said Cooley. Typically, system integrators must reverse engineer and connect to legacy building hardware, which can become very expensive very quickly, he said. He recommended using a sandbox based on open standards that can easily be rolled out to any building to reduce those hurdles. A more consumable layer with common endpoints could increase developer usability when creating innovative building applications.

    Similar to how Twilio made SMS easy, Cooley said he hopes for a similar proliferation in the built world. Many applications could be built with such an abstraction layer. For example, managers could better understand energy usage to reduce consumption, meet regulations and save money. Or, such an abstraction layer could inform predictive maintenance to create automated alerts before failures occur. There are also plenty of ways to improve occupant experience or intelligently optimize the lighting and temperature in a space.

    “Entirely new business models and concepts emerge that we hadn’t considered previously,” said Cooley. For example, he described a “tailgating app” that uses Brick Schema for a security use case. The app prevents building occupants from letting other people “tailgate” into the building behind them after someone swipes their badge. To do so, the app interfaces with many separate building systems (the elevator system, surveillance system, telepresence systems and other sensors) to ensure the number of people in the building matches the number of occupants that swiped in. A lingua franca helps to connect the disparate hardware involved.

    The Future of Building Automation

    This is by no means the first attempt to standardize building data. For example, the Green Button Initiative provides a standard API through which to download utility use data for electricity, gas and water and share it with solution providers. However, according to Cooley, this information only goes so far. Building owners will require more contextual data on-site.

    For example, perhaps a building’s window glazing is causing specific rooms to overheat in the sunlight. Thermal sensors would spot this condition, but bulk energy consumption readings wouldn’t ascertain the root cause. Access to real-time granular data such as current occupancy count is also necessary for developing on-site applications that better refine exactly how human involvement impacts energy consumption.

    Of course, as building systems become more intelligent, there is the growing possibility of privacy infringement. For example, systems that use facial monitoring and recognition could end up storing personally identifiable information. In that case, you “need to give data owners the control to decide what applications can’t or can’t access PII,” said Cooley.

    While this field has many read-only applications, Cooley predicts future write operations will enable more automation with building hardware. This could allow applying ML/AI to anticipate elevator floor calls. Or, a predictive system could cool a room only when a meeting is scheduled. When such data is readily accessible and available for developers, it presents many innovative opportunities to optimize and interact with the built world.

  • Akamai: Buying Linode | Firefox: Not OK | Gone: Google Vaccine Mandate

    Akamai: Buying Linode | Firefox: Not OK | Gone: Google Vaccine Mandate

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Linode gets bought by Akamai, Firefox market share is “measly,” and Google brings staff back to the office.

    1. Akamai + Aker = ‘Synergy’

    First up this week: Why is Akamai buying Linode? Whatever the reason, it’s a big payday for its solitary shareholder: Not far off a billion dollars.

    Analysis: There goes the neighborhood?

    The 100 lb gorilla of edge computing and CDNs is promising not to mess with Linode’s winning open source cloud formula: No change, steady as she goes, etcetera. But how many times have we heard that before?

    Here’s local scribbler Paige Gross: Linode’s $900M acquisition by Akamai is a ‘game changer’

    A household name in the Philly tech scene … CEO Christopher Aker founded the company in 2003, and it’s been bootstrapped ever since, growing to about 250 employees. … Aker has owned 100% of Linode since he founded it.
    …
    Aker said the deal brings the company closer to solving evolving challenges “as cloud services become all-encompassing, including compute, storage, security and delivery from core to edge. … We’ve been talking about ‘alternative cloud’ — alternative to the big guy — and now we’ve sort of validated ourself in this market.”
    …
    The Old City company maintains “well over a million accounts” but has anywhere around 150,000 active users of its platform at any particular time. Linode’s HQ, the bank building at Third and Arch Streets, remains. … For clients and Linode employees, there won’t be too much noticeable change [Linode] says.


    Why does Akamai want Linode? Jonathan Greig asked the CEO:

    Akamai CEO Tom Leighton [explained] that Linode has great customer support and is already in 11 locations, which Akamai is going to “dramatically” expand. … Leighton also noted the September 2021 acquisition of Israel-based Guardicore, a cybersecurity company that offers a micro-segmentation solution to reduce the potential attack surface of corporate networks, secure applications, and meet compliance standards.
    …
    According to Leighton, the company is expecting the cloud compute category — which includes edge applications, its net storage business, and Linode — to reach “well over half a billion dollars in 2023. … We were pioneers in edge computing and now we’re taking a big step forward in cloud computing with Linode.”


    But here’s a worried-sounding zoid.com:

    Well good for them but I hope [Akamai] don’t screw it up. Linode is a great hosting company.


    2. Firefox isn’t OK

    Last week, a journalist innocently asked, “Is Firefox OK?” And people lost their minds.

    Analysis: No, not OK—it’s a big problem for DevOps and the web.

    We need Firefox and Gecko. A Chromium monoculture is bad for the web and bad for DevOps. (Before you ask: No, the existence of WebKit doesn’t change things, thanks to Apple’s ridiculous policies). Much as I tried to say something nice about Firefox last month, its market share is, frankly, pathetic.

    Matt Burgess: Is Firefox OK?

    In the two decades since Firefox launched from the shadows of Netscape … the browser has slid to less than 4 percent of the market—on mobile it’s a measly half a percent. … Its fate also has larger implications for the web as a whole.
    …
    Each year Google pays Mozilla hundreds of millions of dollars in royalties. … In its 2020 financial results … Mozilla listed its total revenue as $496 million. … The Google-Mozilla deal was last renewed in 2020 and is expected to expire in 2023. … Mozilla and Firefox acknowledge that for its long-term future it needs to diversify the ways it makes money.
    …
    Firefox still matters: … The browser market is dominated by Google’s Chromium codebase and its underlying browser engine, Blink. … Microsoft’s Edge Browser, Brave, Vivaldi, and Opera all use adapted versions of Chromium. Apple [has] its WebKit browser engine [but] other than that, Firefox’s Gecko browser engine is the only alternative.


    Firefox, how do we love thee? Let not_count_zero count the ways:

    I still use Firefox because:
    a) I remember Internet Explorer and the standards wars. …
    b) I don’t trust Google. …
    c) Most sites work well.
    …
    I do have questions though. … They’re currently getting around a half a billion‽ What are they doing with it? … This seems really off—really, really off.


    But heed a deeply worried Thom Holwerda:

    The decline and potential demise of Firefox is a massive problem that everybody seems to be kind of tiptoeing around—too afraid to acknowledge that if Firefox were indeed to disappear, we’d be royally screwed. We’d end up right back where we started 20 years ago, with Chrome being the new IE6.
    …
    The situation is especially dire for … Linux users, developers, and distribution makers. … Gnome Browser or KDE’s Falkon can barely be taken seriously, and … are based on Apple’s WebKit, which isn’t a great position to be in.


    3. Google’s Return to Work Plan Drops Vaccine Mandate

    Google is planning “celebrations” to welcome back employees after being fully remote. And in practice—unlike at IBM—this doesn’t mean a vaccine mandate.

    Analysis: Vocal minority wins—or do they?

    It was just three months ago that Google said it “firmly stands behind our vaccination policy.” What changed? It’s unlikely to have been due to a tiny minority of staff publishing a manifesto.

    Jennifer Elias: Google relaxes mandates

    The company will no longer require vaccination as a condition of employment … as it prepares to bring workers back to the office … at least three days a week for a “hybrid” work model. … The company [had previously] told employees that they must comply with vaccine policies or they’d face loss of pay and eventually loss of employment.
    …
    According to Google spokesperson Lora Lee Erickson … the company dropped the requirement … after removing the Jan. 18 deadline it had set for employees to either get vaccinated or get exemption approval. She declined to provide further details on the policy or the reasons for the reversal.
    …
    Google Real Estate and Workplace Services VP David Radcliffe [said Google] is preparing to begin its 30-day transition period to the hybrid work week if conditions continue to improve. He said his team is planning “celebrations” to welcome back employees. … Unvaccinated employees who are approved to enter offices will still need to follow additional protocols, including testing and wearing a mask.


    It’s too simplistic to say the anti-mandate brigade are also anti-vaxxers. For example, raxxorrax:

    I am vaccinated and HR knows this. … But if they officially demanded a certificate, I think I would have called it quits. Many people don’t have that option [but] there are consequences for such unreasonable demands.
    …
    I understand a mandate for vaccinations in certain occupations relating to health. It is something you have to personally accept if you want to work in the field.


    Although a few others are way over at the end of the bell curve. Greg Jinkerson:

    Don’t get excited, [Google is] still evil and stupid. … Now they’re backing down for some reason, [but] this is barely anything notable as far as a rollback of restrictions. [It] is not any kind of encouraging news.


    The Moral of the Story: Failure is the foundation of success—and the means by which it is achieved.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Aleksey Kuprikov (via Unsplash; leveled and cropped)

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

    Updating and Managing Infrastructure-as-Code (IaC)

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

    Announcer: This is Digital Anarchist.

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

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

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

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

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

    Tim Davis: Right.

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

    Tim Davis: [Laughter] Exactly right.

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

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

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

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

    Mitch Ashley: Mm-hmm.

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

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

    Tim Davis: Yep.

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

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

    Mitch Ashley: Mm-hmm.

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

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

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

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

    Tim Davis: Right.

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

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

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

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

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

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

    Tim Davis: Exactly.

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

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

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

    Tim Davis: Exactly right.

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

    Tim Davis: Right. [Laughter]

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

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

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

    Tim Davis: Right.

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

    Tim Davis: Right.

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

    Tim Davis: Right.

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

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

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

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

    Tim Davis: I think so.

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

    Tim Davis: Yeah.

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

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

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

    Tim Davis: Right.

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

    Tim Davis: Yeah.

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

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

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

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

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

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

    Tim Davis: Exactly right.

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

    Tim Davis: It absolutely is.

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

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

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

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

    Tim Davis: [Laughter]

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

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

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

    Tim Davis: Right.

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

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

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

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

    Tim Davis: Absolutely.

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

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

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

    Tim Davis: Exactly right.

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

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

    Mitch Ashley: Alright, take care.

    [End of Audio]

  • Snyk Acquires Fugue to Secure Cloud Infrastructure

    Snyk Acquires Fugue to Secure Cloud Infrastructure

    Snyk today announced it has acquired Fugue as part of an effort to embed security within an infrastructure-as-code (IaC) provisioning tool.

    The Fugue platform combines a unified policy engine with an implementation of the open source Open Policy Agent (OPA) software, dubbed Regula, to ensure security and compliance policies are consistently enforced. OPA provides IT teams with a tool for declaratively applying policies and is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    The Fugue IaC tool also provides pre-deployment security checks for Terraform, AWS CloudFormation, Kubernetes manifests and Dockerfiles. It enables IT teams to create and test custom policies using Rego, the programming language created for OPA. In addition, there are interactive visual maps of IaC templates and the ability to export IaC diagrams that IT teams can use for planning and approval processes.

    Josh Stella, the former CEO of Fugue who is now a chief architect for Snyk, said Regula is designed to make it possible to apply those policies to both cloud-native and legacy monolithic applications. Tighter integration with the cloud security posture management (CSPM) tools that Snyk provides will make it possible to provide developers with an instant feedback loop as they provision infrastructure, he added. Armed with that intelligence, it becomes less likely that mistakes will be made and that cybercriminals can take advantage of those, noted Stella.

    DevOps teams should also expect to see Fugue integrated with the artificial intelligence capabilities Snyk gained with the acquisition of DeepCode, a provider of an interpretable machine learning semantic code analysis tool that scans code anywhere from 10 to 50 times faster than existing approaches. In total, Snyk has acquired five companies in the last 18 months, including CloudSkiff, FossID, Manifold and DeepCode.

    Misconfigurations of IT infrastructure have emerged as a major issue in the cloud era. Developers often have little to no cybersecurity expertise, and using application programming interfaces (APIs) to provision IT infrastructure themselves increases the chance that mistakes will be made. The acquisition of Fugue creates an opportunity to address that issue at a time when the management of infrastructure and applications is converging, said Stella.

    The amount of focus on cloud security also is increasing as part of a larger discussion involving software supply chains that increasingly becoming targets of attack. Cybercriminals are becoming more adept at scanning for vulnerabilities created when developers, for example, inadvertently leave open a port on a cloud service through which data can be exfiltrated.

    It’s not clear just how far responsibility for cybersecurity will shift left toward developers in the months and years ahead. However, as more intelligence is incorporated into the tools that developers use, the easier it will become to automate DevSecOps best practices. In fact, the goal should be to make it easier to build more secure applications faster rather than forcing organizations to slow down to deal with security issues that should never happened in the first place.

  • IBM ‘is Ageist and Sexist’ | IBM Mainframe-aaS | IBM Vaccine Mandate

    IBM ‘is Ageist and Sexist’ | IBM Mainframe-aaS | IBM Vaccine Mandate

    Think! Welcome to Big Blue Week here at The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: IBM’s employment practices scrutinized, IBM z/OSaaS breaks cover, and IBM encourages staff back to the office.

    1. ‘Dinobabies’ and ‘Dated Maternal’ Workforce Woes

    First up this week: IBM’s defense in an employment age discrimination lawsuit looks to be shredded. Internal emails “appear to show high-level discussion about paring the ranks of older employees.”

    Analysis: Not a good look

    According to one of the plaintiff’s lawyers, unnamed “top IBM executives were explicitly plotting with one another to oust older workers … to make room for millennial employees.” On the face of it, they seemed to be doing the polar opposite of the Age Discrimination in Employment Act.

    Noam Scheiber: Making ‘Dinobabies’ Extinct: IBM’s Push for a Younger Work Force

    Top IBM executives were directly involved in discussions about the need to reduce the portion of older employees … sometimes disparaging them with terms of art like “dinobabies.” … Documents made public by a Federal District Court … show executives discussing plans to phase out older employees.
    …
    The newly unsealed documents, which quote from internal company emails … show top IBM executives specifically emphasizing the need to thin the ranks of older workers and hire more younger ones. [One] email refers to IBM’s “dated maternal workforce,” an apparent allusion to older women, and says: “This is what must change. They really don’t understand social or engagement.”
    …
    Adam Pratt, an IBM spokesman, [claimed,] “IBM never engaged in systemic age discrimination.” [He] said that some of the language in the emails “is not consistent with the respect IBM has for its employees” and “does not reflect company practices or policies.”


    Yikes, ageism and sexism? Experienced staff are valuable, says MrBanana:

    I did some time at IBM [and] remember being invited to a meeting with a new group, headed by a new “thinker,” who had something to present to myself and a colleague. We walked past the foosball table to the meeting room. Naturally the room had no chairs, and was covered in multi-coloured Post-it Notes. Once they had gone through their mood boards and the non-linear presentation of this new idea, I turned to the other old geezer in the room. “Didn’t we look at something like this 8 years ago?”

    “Yeah, we worked out that compute power just to run the UI for one session wouldn’t be available for a couple of decades.” The children were somewhat disappointed, and (fortunately) we were never asked back to their romper room.


    But experience can be both a blessing and a curse, learned aahortwwy:

    I experienced both sides of this in five years at a company in hypergrowth. … I learned so much at that job: … In year 1, I was determined to accomplish X and ignored the skeptical comments of some colleagues who’d been at the company longer than me. I failed and wasted some time. In years 4 and 5, new colleagues were determined to accomplish X and ignored my skeptical comments.


    2. IBM Wazi as-a-Service Confusion

    “Mainframe” is not a dirty word. It’s secure, vertically scalable, and it put the VM in VMware. Now, what IBM Wazi did for on-prem LPARs, Wazi aaS promises to extend to hosting z/OS instances.

    Analysis: Mainframe-as-a-service reinvented

    Mainframes and cloud-native DevOps need not be incompatible. To modernize legacy apps using hybrid cloud instances for dev/test—and even prod—can be a big productivity boost. But isn’t it weird that IBM spun out its mainframe-as-a-service zCloud offering only a few months ago?

    Mike Vizard: IBM Shifts Mainframe App Testing to the Cloud

    While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. … IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.
    …
    IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year, [which] will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud. … At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs … using a cloud-native set of DevOps tools that run in a Kubernetes environment.
    …
    Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort.


    OK, boomer, why are we talking about 1960s mainframes on devopsy.kinsta.cloud? Here’s ArchieBunker:

    Mainframes are different beasts altogether, almost alien when you compare them to PC hardware. You have binaries written for the S/360 system in the 1960s? Good news you can still run them natively without a recompile.

    You think virtualization and containers are a hot topic? IBM was running multiple OS instances inside a VM in the 1970s. … The engineering is incredible.


    But z/OSaaS? It’s déjà vu time for Beleagured Greybeard:

    “Cloud Managed Services for z” AKA “zCloud” has been around for over 10 years. … IBM offloaded it with the Kyndryl spin, so its odd that they now want to re-invent it.
    …
    If it’s a strategic platform, why didn’t they hold onto it instead of spinning it off to Kyndryl? Sounds like yet more daft leadership decisions.


    3. IBM’s Return to Work Plan has Vaccine Mandate

    IBM wants to “keep employees safe” as they return to office work after being fully remote. In practice, this means a vaccine mandate.

    Analysis: IBM Digital Health Pass is divisive to vocal minority

    Although there are exemptions on medical or religious grounds, IBM has promised to place dissenters on unpaid leave. As you might expect, the policy has a few employees up in arms.

    Cassie Werber: How Salesforce, IBM, and HSBC are approaching return to work

    When the pandemic hit, and IBM moved 95% of its workforce to fully remote, it was pleasantly surprised to discover no drop in productivity. … Still, they planned to return to offices.
    …
    The company saw this as a way to keep employees safe. … One example … is its development of the IBM Digital Health Pass as an alternative to vaccine cards or paper vaccine certificates, which they use to make sure all the staff that come into their offices are vaccinated.
    …
    Arvind Krishna, IBM’s CEO, meanwhile came up with what he called the IBM Work From Home Pledge. [It] included commitments to flexibility, kindness, sensitivity to family, setting boundaries, and acknowledged video fatigue. It concluded with a commitment to “be connected.”


    Tricky to “be connected” if you’re not allowed back in the building. Anne D’Innocenzio, Heather Hollingsworth, Tali Arbel, Mae Anderson, Ken Sweet, Matt O’Brien and Dee-Ann Durbin:

    IBM software engineer Justin Albano said his company recently notified employees that it would be revoking badge access to workers who aren’t vaccinated or haven’t proved that they are. “We’re not able to enter an IBM office at this time,” said Albano.
    …
    He said some workers have successfully sought religious exemptions but “my thought process was I shouldn’t have to explain to my company my faith” to get out of a policy that’s “immoral in its foundation.”


    What’s the alternative? With a perspective, it’s Chris Haney:

    Or, get the vaccine. Protect yourself and the people around you. You people really are detached from reality.


    The Moral of the Story: Those who know do not speak; those who speak do not know.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Marcin Wichary—cc:by; leveled and cropped (ask your parents)

  • Heterogeneous Hardware Needs Universal Software

    Heterogeneous Hardware Needs Universal Software

    As hardware advances and diversifies, we’re entering what many see as a new golden age of computer architecture. However, the idea of an ever-expanding hardware landscape can be daunting for software developers, because while hardware diversity is wonderful for price and innovation, it can lead to spiraling software complexity on the back end. So many software tools are specific to the hardware they run on that a world where CPUs, GPUs, FPGAs, ASICs, DSPs and more are freely intermingled feels overwhelming; an invitation to interoperability headaches and spiraling tech overhead. The question on the minds of developers is how to navigate this constantly changing ecosystem to take advantage of the new world of hardware acceleration without driving themselves crazy in the process. 

    The challenge for developers is that, if we look historically, every time a new piece of world-changing silicon shows up, it often comes with a new software stack of tools. With heterogeneous hardware innovation moving at a nearly untrackable pace already, keeping up with the software end is beginning to feel untenable. In response, a new philosophy is emerging: We should be able to have a common set of tools, libraries, frameworks and compilers that can address a wide variety of accelerators in a “silicon agnostic” way. 

    Anyone doing DevOps work today should be asking, “Are the tools we are adopting ready for the heterogeneous hardware future?” Rather than using proprietary stacks exclusive to individual vendors’ concepts of how acceleration should work, we should be thinking about abstraction layers that allow us to move to open software stacks that work across multiple vendors and architectures. 

    This philosophy is central to a number of movements—oneAPI being one example—of asking for libraries, compilers and analysis tools that are more versatile. It’s incumbent on any future-conscious developer to analyze the tools they’re using and ask if they are preparing for the future or locking them into a single solution that excludes you from other innovations. 

    When it comes to navigating the changing developer landscape, it’s particularly important to look at the multiple-vendor piece of the puzzle. One of the signature strengths of computing and electronics is its ability to interoperate. Without compatibility between platforms, we end up locked into single solutions that don’t take advantage of the diverse landscape of innovation available to us. If systems are built from the ground up with mixing and matching in mind, we don’t have to change our software tools to adapt to new technologies and we can use the same languages, libraries and analysis tools we are used to. 

    It’s important we take on this work now because hardware diversity is not just at an all-time high, its momentum is only growing. In the past when the hardware landscape was more limited, switching to different toolsets for different CPUs was a feasible, if inelegant solution. Today’s computers, however, have computational capabilities from multiple vendors. If my tools don’t stretch across all of its ecosystems, I end up in a complex mess very quickly.  

    A particularly relevant example can be found in supercomputing, one of the most exciting and fast-moving areas of innovation in the developer community. What is the most exciting thing about supercomputing? It’s heterogeneous, allowing multiple architectures to take on specialized hardware acceleration for the different tasks for which they are best suited. The Aurora supercomputer, for example, is planned to achieve up to 2 exaflops of performance—a staggering number (the first supercomputer I helped design had 1 teraflop—or 2 millionths of Aurora’s performance). The amazing capabilities of these machines are only possible because of advancements in heterogeneous memory technologies, storage capabilities, sophisticated CPUs and GPUs all working together seamlessly.  

    The advancements we’re seeing in supercomputers, as always, will ultimately filter down into lower-level systems. In the near future, regardless of the type of work you do, enormous computing power is coming online. We need to make sure that our libraries and tools can take full advantage of it when it arrives.

    Two great places to learn more about activities to help software be open, multi-vendor and multi-architecture for heterogeneous programming are:  https://sycl.tech/ and https://www.oneapi.io. There are numerous online tutorials, a link to the SYCL book (free PDF download) and much more.

  • CircleCI Adds Free Unlimited Access Tier to CI/CD Service

    CircleCI Adds Free Unlimited Access Tier to CI/CD Service

    CircleCI has added a free unlimited access tier to its continuous integration/continuous delivery (CI/CD) platform.

    Jim Rose, CircleCI CEO, said in contrast to other ‘freemium’ offerings, CircleCI’s free tier provides developers and DevOps teams with frictionless access to all the premium capabilities of the platform. Those capabilities include up to 6,000 build minutes per month, unlimited users, the ability to fine-tune pipelines using caching, concurrency, test splitting, security tools and health metrics.

    CircleCI claims more than 200,000 teams now employ its CI/CD platform. The freemium tier is intended to make it easier for a DevOps team to take advantage of a CI/CD platform as they begin an application development project, noted Rose. As that project evolves and matures, many of those teams will eventually require commercial support and other services provided by CircleCI, he added.

    The free tier of the CircleCI cloud service comes as many organizations attempt to accelerate the rate at which they can build and deploy applications. Digital business transformation initiatives, in particular, have become a much higher priority in the wake of the COVID-19 pandemic. A free tier of a CI/CD service is likely to encourage more experimentation simply because it reduces the level of overhead associated with setting up an application development environment.

    As the number of applications being developed continues to steadily increase, competition among CI/CD platform providers is becoming more intense as the number of organizations adopting DevOps best practices to accelerate application development increases. At the same time, more DevOps teams than ever are relying on cloud services to host CI/CD platforms in the wake of the COVID-19 pandemic.

    It’s still not clear whether DevOps teams will opt to rely on a proprietary platform versus an open source platform. While an open source platform prevents organizations from vendor lock-in, the ease of use of a cloud service may lessen those concerns as the cost of switching from one cloud service to another declines.

    One way or another, usage of CI/CD platforms will increase sharply in 2022. It’s not uncommon for different DevOps teams within the same organization to employ different CI/CD platforms despite efforts to encourage standardization. In the name of productivity, DevOps teams tend to exercise a fair amount of autonomy within many organizations.

    The biggest challenge, of course, will not necessarily be building applications but deploying them. Despite the availability of CI/CD platforms, the processes that most organizations rely on to deploy an application are still largely manual. In the age of the cloud, however, it should become easier to automate application delivery thanks to the APIs cloud service providers expose. In fact, 2022 may be the year that DevOps teams finally master CD. Providers of CI/CD platforms, of course, have a vested interest in making sure the full promise of an integrated CI/CD platform finally becomes an everyday DevOps reality.

  • Infrastructure Access Management a Growing DevOps Priority

    Infrastructure Access Management a Growing DevOps Priority

    Organizations plan to address access management over the next 12 months, as the need to secure and streamline infrastructure-wide access controls serves as a prerequisite to other initiatives, like zero-trust.

    This was one of the key findings of a survey of 600 DevOps professionals conducted by Pollfish and sponsored by strongDM. The report also found that legacy access processes created severe team inefficiencies.

    These inefficiencies require intensive time and resources to fix and block agile development practices: Nearly nine in 10 organizations surveyed said they required two or more employees to review and approve access requests and that those could take days or weeks to fulfill.

    The survey also indicated that organizations continue to use access management practices that are not secure and that make it difficult to track and audit users and permissions of critical business systems.

    Tim Prendergast, CEO of strongDM, said as more jobs become technical, there’s a bigger need to deliver access to more people–and that can have a severe impact on a company’s ability to remain secure. He explained that when 65% of organizations are reporting their teams used shared logins—and over 40% used shared SSH keys—there’s virtually no way for you to know who is in your infrastructure or the havoc they may be wreaking.

    “This makes it difficult to pinpoint any leakage or loss because you have 20 copies of your house key floating around,” he said. “It’s an example of the trade-off most organizations make when it comes to speed and ease of access versus ensuring that access is secure.”

    Survey respondents said their biggest challenges were the time required to request and grant access (52%) and the task of assigning, rotating and tracking credentials (51%).

    Hurry Up and Wait

    “Using current approaches to access means you’re hiring these high-paid, technical resources and telling them to hurry up and wait,” Prendergast said.

    Nearly half (47%) of respondents said they struggled with onboarding employees and contractors and Prendergast pointed out that one in four organizations said simply getting approval for access required a process that involved four people.

    “Think about that—in 25% of organizations, you have technical resources basically twiddling their thumbs while they wait to get access to this database or to that Kubernetes cluster,” he said. “Now multiply that by however many databases, servers, employees and third-party vendors that you have. And that’s not even counting when new technologies like Kubernetes are added to your infrastructure. Eventually, even just the frustration of your team as they wait for access becomes a liability.”

    2022: A Year of Convergence

    Prendergast predicted 2022 will see DevOps and security converge beyond what we’ve already seen with DevSecOps, where it has been heavily focused on shifting left and bringing security into the development cycle earlier.

    “This convergence will be marked by new workflows, technologies and solutions that not just improve security, but that also improve the development cycle,” he said. “One great example is optimizing infrastructure access—when done right, you can improve your security posture with zero-trust methodologies while also making it easier for DevOps teams to access systems quickly and easily.”

    He added that two of the biggest workforce dynamics facing zero-trust are remote work and the Great Resignation.

    “You used to have this environment where you’d have to be physically present or on the VPN to have access—remote work broke that,” he explained. “And now you also have this large number of employees leaving their jobs. Do you know what systems they had access to? How do you know if all of that access has been turned off? What happens if they were using shared credentials?”

    Prendergast said that’s why addressing access is critical to meeting this challenge and getting to modern security—if you don’t know who has access to what or what they can do in each system, you can never get to zero-trust.

    “Organizations need to find a way to understand the relationship between each technologist and each technology and then be able to track and audit those relationships,” he said. “Until you do that, you’ll have a really hard time getting to zero-trust. These are the table stakes for modern security.”

  • IT Ops Trends: Cloud, Containers and COVID

    IT Ops Trends: Cloud, Containers and COVID

    Almost all companies are modernizing their IT infrastructure to remain competitive, with the focus firmly on migration to the cloud and the use of dynamic infrastructures. In a recent Trends in IT Ops 2021 survey, more than 160 IT professionals were asked how the implementation of IT strategies affected their day-to-day work. The results provided an impressive insight into the current work priorities of system administrators and IT Ops in general.

    According to the survey, most administrators believe that monitoring cloud (79%) and container (73%) environments will take on a more important, or much more important role for them in the future. Additionally, 59% of those surveyed agree that their job role has evolved over the years due to cloud computing and containerization.

    Not all IT Teams are Equal

    However, the data also shows that the changes are not affecting every IT team equally. For example, 37% of all respondents say that cloud solutions are not relevant—or less relevant to them on a day-to-day basis. This response shows that on the one hand, system administrators see cloud computing as an essential topic. However, on the other, the impact in practice is not felt to the same extent by every administrator. These responses show that not every administrator has to deal with cloud platforms on a day-to-day basis, with some being ‘siloed’ into dedicated teams that may not interact with the broader corporate cloud strategy. In addition, not every organization has fully committed to the cloud, with some finding their migration hindered by applications that are not suited to cloud migration.

    In the survey, 45% of respondents also said they believe the importance of monitoring physical infrastructure will not change in the next few years. However, 43% believe that monitoring physical systems will become more important or much more important. Conversely, a mere 1% replied that they thought physical infrastructure monitoring was less critical. 

    Taken together, these responses demonstrate that, despite the excitement around the cloud, many organizations take a hybrid approach to infrastructure. IT Ops and administrators recognize the importance of monitoring cloud systems and dynamic assets while, at the same time, the monitoring of local systems remains relevant or is even expected to gain in relevance.

    Network Management and Automation

    Cloud and containers enable faster growth of IT environments and promote digitalization. However, they also lead to a sharp increase in data traffic and more complex networking of systems. As a result of these changes, the demands on local networks are growing. This increasing demand demonstrates the importance of network management tools. 81% of respondents said that solutions in this area are relevant, or very relevant to them in their day-to-day work.

    This year, the move to a home office joined the trend towards migration to the cloud, containers, and network monitoring. In the wake of the COVID-19 pandemic, many IT departments had to adapt their infrastructure to allow employees to work from home offices. However, most administrators were relatively stress-free, with 54% saying they had no trouble adapting infrastructure to meet remote work requirements.

    Automation is also a key issue. For example, 81% of all respondents say projects that deliver deployment and configuration automation have been relevant in their organizations in the past 12 months. In addition, 92% say that automation tools are relevant, or very relevant to them on a day-to-day basis. 

    Cloud, Containers and COVID

    The Trends in IT Ops 2021 survey shows that system administrators are concerned with cloud computing and containers and several other topics. In addition, most administrators recognize the increasing importance of monitoring cloud environments and containers. That said, administrators continue to see monitoring networks and other physical infrastructure assets as critical, and some system administrators see increasing importance in monitoring this vital area. 

    In addition to the topics outlined here, respondents also provided feedback on topics such as virtualization, application performance monitoring and network management.

  • Enable Multi-Cloud Networking With Automation

    Enable Multi-Cloud Networking With Automation

    As we enter a new era of technology, we’re experiencing a “third wave” of cloud innovation that brings new complexities into the IT landscape, mainly centered around multi-cloud networking. With every wave of cloud technology advancement, networking components are becoming more complex and distributed across multiple groups. Further, multi-cloud networking brings new challenges around connecting and managing across dispersed environments comprising private and public clouds, along with physical data centers. Organizations must unify their network operations in a way that enhances their capabilities into a new level of skill and efficiency. 

    Augment Strategies

    Looking forward to new capabilities offered by automation tools, technology leaders can augment their 2022 IT strategies. How?

    • Support a more seamless transition to cloud within hybrid IT infrastructures.
    • Cultivate new values brought to an organization from network engineers.
    • Enable executive leaders to easily align operations across multiple teams – spreading innovation across the entire organization.

    Connecting Hybrid IT Infrastructures

    As more IT leaders invest in an assortment of digital tools to streamline network operations – some engineering teams might feel more reluctant to leave behind old processes or feel intimidated by the multitude of new capabilities at their fingertips. With modern tools and processes gradually being incorporated into the workflow of IT departments, it’s critical to find the right balance in this “hybrid” environment, which will include a combination of both traditional on-premises systems with new cloud applications. Automation can help smoothen the transition to new technologies by simplifying manual processes previously relied on, while also bridging together the plethora of systems for easier management.

    Leveraging Cloud-native automation

    When bridging together disparate systems, leveraging cloud-native automation solutions that provide API capabilities can make all the difference. These solutions not only build the appropriate connectivity required between different applications but also provide the flexibility to manage networks in a cloud-friendly way. Additionally, automation can be deployed to ensure compliance of device configurations that span both on-premises network devices, as well as those connected to cloud-based infrastructures. For example, with automation it’s possible to quickly perform a configuration back-up, check for compliance and execute “intelligent remediation”. This translates to a network device or group of devices that can be backed up and the current configuration compared against the existing golden configuration standard. Changes can be automated to ensure the network is adhering to the current compliance standard. Further, automation is changing the way that IT teams approach daily operational challenges.

    Evolving Value in Network Teams

    Network engineers play a unique role in organizations by performing tasks that require years of training, and an understanding of the complex ins and outs of their internal systems. Although the performance of these manual tasks might be assumed to be the value-driver for engineers – the adoption of new technologies has pushed the boundaries of what network professionals are familiar with. In turn, this has evolved expectations for what constitutes true success and impact. Organizations are looking for engineers to harness the power of these new technologies and execute on a modern strategy – utilizing automation to support this new mindset. 

    Streamline the Adoption of Integrated Multi-cloud Environments

    Breaking down the silos between technologies and teams is critical in order to understand how to get the most out of their investments. For network teams to fully embrace multi-cloud networking, they need to practice deeper management, segmentation, security and control of cloud networks. As with segmentation – automation can help network teams lean away from using overlays, and instead use the native software tools in AWS, Azure, etc. Additionally, many network teams might be under the false misconception that automation requires them to learn to program and write code – when in many new tools, network elements can be managed and orchestrated directly from within the code of an application. This will make network programmability part of the cloud software fabric, and streamline the adoption of integrated multi-cloud environments. Network teams can implement both compliance and automation to standardize both on-prem or new cloud programs, simultaneously building their automation skills without the need to write a single line of code.

    Aligning Operational Efficiency

    When investing in new IT infrastructures across organizations, IT leaders typically build up their programs “vertically” within each department. However, this creates a gap between teams, as each is operating in separate models and functionalities – driving up unnecessary costs and inefficient business practices. To successfully align multi-cloud initiatives for increased operational efficiency in 2022, IT leaders will be required to invest more “horizontally” across their organizations – and in doing so, incorporate automation tools to reduce time and stress. 

    Implementing NaaS

    Achieving operational efficiency can reduce the time and stress experienced by IT teams – this is where the adoption of networking-as-a-service (NaaS) tools can play a beneficial role. IT leaders can invest in networking services directly from the cloud rather than building a new network. Over the next year, as cloud infrastructure expands, NaaS implementations will in tandem grow in importance – enterprises and other organizations (including service providers) will have opportunities to leverage cloud infrastructure without building new networks themselves. Automation tools can help accelerate the time-to-complete and automate the highest percentage of tasks in the activity, eliminating as much idle time as possible.

    Moving Models and Making Improvements

    When considering the investment in these types of tools, it is important to keep in mind how they impact the entire process versus individual tasks. By automating an entire process, not just individual tasks, the operator gains the flexibility to do more in much less time with fewer resources — making innovation possible. With increased flexibility and more time available, engineering and operations teams can focus their attention on strategic activities of greater value instead of performing routine, time-intensive activities. Operations are improved when IT leaders can move from a “human-centric” paradigm to an “automation-centric” model. For example, for maintenance checks, the team can let systems run an increasing number of pre-checks in seconds – enabling the process to execute more efficiently and safely. The key is adopting a model that automates the entire process versus individual tasks.

    Moving Forward

    In the next year, as more workplaces operate in hybrid models, IT leaders will need to evolve their processes to not only unify operations/approaches for remote and in-person employees – but move forward with this new wave of cloud modernization. In doing so, automation can help mitigate and manage the challenges that come with multi-cloud networking,  bolstering skill and efficiency for long-term business impact.