devopsy.kinsta.cloud

Tag: agile infrastructure

  • How Work-From-Anywhere Impacts DevOps

    How Work-From-Anywhere Impacts DevOps

    Brian Lavallée from Ciena talks with Mike Vizard about how the work-from-anywhere movement has impacted DevOps, networking and security. The video is below, followed by a transcript of the conversation.

    Mike Vizard: Hey, guys. Thanks for the throw. We’re here with Brian Lavallée who is senior director for solutions marketing at Ciena. Brian, welcome to the show.

    Brian Lavallée: Thanks. Nice to be here.

    Mike Vizard: You guys just put out this study talking about what’s happening on the technology impact from working from home. A lot of folks are accessing cloud resources. They have home networks that may or may not be up to the task. Are we looking at some sort of networking crisis coming up as we move to working from anywhere? Do people understand that bandwidth is going to be an issue?

    Brian Lavallée: I wouldn’t say it’s a crisis, but it is a work in progress. Just over the last year, year and a half, the global pandemic, our homes have turned into the new branch office, the new classroom. People are learning, playing, and working from home, and it’s put additional stress on the network. One of the main challenges is speeds, because now you have two, three, four people accessing the same broadband connection from home at the same time, and then you have the whole security aspect, where if your home is the new branch office, very often you need additional security to do work, not only with your head office, your colleagues, but also with your cloud applications.

    Mike Vizard: I have found myself trying to fight for bandwidth with an 11-year-old, so I know what the issues are and what the problems can be. Do you think companies, as we go forward, are going to turn around and say to their employees, “Here is the router we want you to use”? Are they going to give them that router, or the access point at home? How far will they go to make all this happen and maybe provide that additional layer of security?

    Brian Lavallée: Yeah, I think, for sure, adding additional security, even availability, a more resilient connection is necessary going forward. Companies or enterprises are going to implement this differently. Some may do a lot of their security capabilities in the cloud. This allows you to have a centralized location to do all your security, you know, talking about SASE, _____ connectivity, and because it’s centralized, it’s easier to implement and control, rather than having specialized devices or specialized software sitting on everybody’s laptop. If you’re a large enterprise, you can have thousands to many thousands of people working from home, so centralizing your security aspect with a high-speed connection is probably the way moving forward.

    Mike Vizard: What impact does that have back on the core networks? I mean, if everybody has suddenly got more bandwidth at the edge, does that have a cascading effect up through the rest of the network infrastructure? Do I need additional core routers or networks? How will this play out in your mind?

    Brian Lavallée: Yeah, _____. Content is created and consumed at the edge, and that’s from humans or machines ‒ think sensors, cameras, and so on. Definitely, as we open up the access ramps, 5G is a way of opening up the wireless access ramp, plus you have a variety of wireline broadband technologies for the home, even the offices. For sure, it has a knock-on effect into the core network because, if you think about it, most of the content and applications that you access, whether it’s on your smart phone, your laptop, tablet, or whatever device you’re using, it’s sitting on a datacenter somewhere. That could be a datacenter close to you, an edge datacenter maybe sitting in the same city as you. It could be a datacenter on the other side of the world sitting in Norway or Sweden or Finland.

    Mike Vizard: I’m feeling like a lot of the applications that people are starting to build, consume data and analyze data at the point at where it’s created more, it’s more happening out at the edge. Is there a lot more sensitivity around latency? Will the laws of networking physics come back and bite us soon, and are we seeing new classes of applications?

    Brian Lavallée: Yeah, and that’s a good question because it leans into the topic of discussion, one of the hotter ones today, which is edge computing or edge cloud. By putting storage and compute access closer to the end-users ‒ again, those end-users could be humans or machines ‒ it does inherently reduce the latency only because you have a shorter physical distance to travel. But, we have to remember latency is not just about distance, it’s about the amount of network nodes that are sitting between you and your content, so the more network devices you go through ‒ switches, routers, and so on ‒ the more latency is incurred and accumulated. Pushing the storage and compute closer to the edge with high-speed connections is a very good way of reducing latency, and it also opens up a whole bunch of new applications where latency is a critical factor beyond just increased speed.

    Mike Vizard: I feel like right after the pandemic, we sent everybody home, we gave them their little wireless network, we hooked them up with a VPN, and they accessed the applications in the office. Then, they went out to the cloud and they had this kind of backhauling effect of the network traffic flow. You mentioned SASE. Are we going to change the way we think about how applications are deployed and how we access them, whether they’re up in the cloud? Is the routing concept that we’ve known all these years changing? How do you think we’re going to go forward from here?

    Brian Lavallée: Yeah, so I think the increased adoption of cloud-based services is an unstoppable juggernaut. It is happening. There are security concerns. Our survey that we did, the study, we did show that there was a security concern of moving more and more into the cloud, but the cloud providers, the telecom operators, they’ve done a lot of excellent work over the last few years to address security, make increased security for their end-users. The cloud-based service providers, they realize that security is top of mind above everything else, so I think that will continue going forward. As more and more end-users are accessing cloud-based applications and content, the network becomes a critical factor because the network now is sitting in between you and the content you’re trying to access.

    Mike Vizard: Do you think the bad guys have figured all this out and they’re targeting people at the end point now and looking at these slightly misconfigured networks? Sometimes we’re using fraud RDP protocols. Are they getting it? Are they after us?

    Brian Lavallée: They’ll always be there, nefarious actors, bad actors, whatever you want to call them, so they will always be there, but the cloud providers, the telecom operators, they know this, so they are consistently upgrading, modernizing, and putting increased security capabilities into their network. It’s always going to be a battle of people who want to do not so good things with the network and content, and the people that actually run those datacenters and networks. I think that will continue going forward, it’s kind of human nature, but we’ve made great strides as an industry, and that’s across IT, telecom, and cloud-based services in terms of security. With more and more people from home, I mean right now we’re living in probably the largest working-from-home experiment of our species, and, if you think about it, the network, it has bent in a few places, right?

    Most of the networks are running hotter, but it hasn’t broken. The Internet has not broken. A lot of people early on thought that if everybody moves home, it’s not that you have more capacity coming to the home, but the traffic patterns have changed. During the day, when a lot of people went to school and work, the traffic was to the schools and the head offices, but now the whole traffic pattern has moved into the home. Although a lot of people were concerned, I think the telecom operators deserve a lot of credit. The network has bent in a few places, but it hasn’t broken, and they’ve just learned a lot over the last year, and the networks will just be that much more reliable going forward.

    Mike Vizard: Prior to the pandemic, the carriers were trying to encourage people to offload from the network and use WiFi. Now we have 5G, and people are talking about 6G and who knows what comes after that. Are we getting to a point where we can just run 5G into the home? Will that get cost-effective at some point and we won’t have all these WiFi routers, or will it always be some sort of a balance between 5G, 6G and WiFi and we have to figure it out?

    Brian Lavallée: Yeah, I mean my personal opinion on that, I think it will always be a mix of technologies. I’ve been in this industry long enough to know that a technology network completely disappears, at least not in my career. It always has places of use. The big difference with 5G over 4G LTE and previous technologies, and even WiFi, previous generations of mobile technologies, it brings a lot of new benefits to the table, right? If we look at the faster speeds, this is what gets the most press coverage because that’s what people will see right away, but it also brings much lower latency. We’re talking order of magnitudes lower latency. It connects to a wider variety of connected devices, such as sensors and smart devices, and then we have this whole concept of network slicing, which can guarantee end-to-end performance.

    You can guarantee the speed, latency, and resilience. We haven’t had that in the past with any mobile network generation, and, to a large extent, we haven’t even had that on the wireline technologies. So, 5G coming right into your home, if you think about it, if you’re a network operator, it’s much easier just to send a 5G hotspot, it could be a router, residential gateway to somebody’s home, they turn it on, they plug it in the wall, and it discovers the mobile network and then BOOM, you’ve got one-gigabit-per-second capacity right to your home. That is, I think, the way of the future in many cases, but there are some technical challenges that still need to be overcome. But, most operators are looking at 5G fixed wireless access to the residential, but even businesses as something in their toolkit going forward to compete with wireline technologies.

    Mike Vizard: Do you think there is a rebellion coming among the end-users who are using this stuff? When you hear them, they’re kind of complaining a lot about the experience, so do you think that at some point they’re going to start picking what companies they want to work for based on what kind of work-from-home, work-from-anywhere experience they can get? Will that factor into hiring and retention more than it has in the past?

    Brian Lavallée: Yeah. I mean, the network is critical infrastructure today, especially for the younger generation who were born and raised on having always-on connectivity. I think that will continue going forward. But, as more people work from home, I know we hear a lot of talk about the new normal, what ire the workplace, for instance, or the school systems going to look like after the pandemic subsides? We don’t really know. But, what I think we do know is more people will be working from home. I see it in my personal life, I see it with my colleagues, I see it with friends and family. Their companies are looking at implementing working from home at least a couple of days a week. There are a lot of benefits to the company to do this, as well, so the network will become that much more important.

    I think people will shop around if the provider they have, the network provider, is not giving them the performance that they need, and it will become a highly competitive marketplace. I mean, it is pretty competitive now, but I think it will be that much more so going forward in terms of speed, latency, and availability, the three main things that you need with a high-speed connection to your home.

    Mike Vizard: I might even one day factor networking costs into my compensation packet, but we’ll see what happens.

    Brian Lavallée: There you go.

    Mike Vizard: What is your best advice to people who are on the IT side of this equation, they’re the network managers, they’re security people. What is the conversation that they should be having higher up the food chain to the board of directors about what needs to happen to really enable this next wave of work?

    Brian Lavallée: Yeah, I mean, the higher speed to the home is something that a lot of people talk about. We just talked about it earlier, more people working, playing, and learning from home, so capacity will always be at the forefront of discussions and having competitiveness for an operator with another operator. But, I think increased security features, this could be wrapped around a broadband connection to your home, so rather than just buying a high-speed pipe to your service provider, they would also provide you with SASE type of capabilities, so security, firewalls, and so on. I think looking at bundling, IT services with the connection is definitely the way to go. It is a differentiator, and it is what people will be looking for because if you’re the average home user, whether it’s for playing, learning, or working, you really don’t care what technology you’re buying, as long as it’s cost-effective and it meets your needs.

    I think my advice for the operators is to look at what is available recently, some of the newer technologies ‒ virtualization and SASE technologies and the SD _____, a whole bunch of other technologies ‒ and start to wrap these into a bundle that you solve most, if not all of the needs of the subscriber, and then you could differentiate far above and beyond just a higher speed.

    Mike Vizard: All right, guys, you heard it here. Faster things that are insecure do not necessarily represent progress. Hey, Brian, thanks for being on the show.

    Brian Lavallée: Happy to be here. Thank you.

    Mike Vizard: All right, guys, back to you in the studio.

    [End of Audio]

     

  • 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.”

  • The Need for Agile, Adaptable IT Infrastructure

    The Need for Agile, Adaptable IT Infrastructure

    Through the adoption of Agile concepts and new best practices such as automated testing, organizations can move beyond the innovation curve and bolster their IT infrastructure. In fact, the need to build agile and resilient IT infrastructure has become increasingly pertinent over the past 18 months. 

    From remote working and managing the diverse needs of employees in remote locations to the growing rates of cybercrime, the move from the physical world to the virtual one has seriously impacted the ability of organizations to operate. It comes as no surprise that business leaders are increasingly investing more in new tools and technologies to improve their IT infrastructure, transform operations and drive business value. 

    That said, it still remains relatively rare for enterprises to wholly adopt Agile approaches and techniques, despite the fact that doing so can help improve the efficiency at which goods and services hit the market. The fact is that many technology companies still do not use Agile as it is difficult to implement at scale. In addition, Agile transformation demands a cultural change, which can often take time. 

    Nevertheless, sooner or later, Agile IT will need to be implemented across businesses in various industry sectors, as well as across all branches of an organization. Our experience has been that Agile transformation will help your business grow and succeed. 

    What is Agile IT? 

    Agile is a philosophy—a mindset that can be applied to improve the provisioning, management and operation of digital infrastructure. Agile promotes business-led development, whereby a product owner and software development team collaborate as a single entity to deliver tasks that are prioritized based on business value. These tasks are also delivered over a short timeframe, such as via two-week sprints. 

    Essentially, your infrastructure is far more likely to be both secure and resilient if Agile concepts are implemented throughout the software engineering process. As a result, new digital products can be delivered to customers more quickly. For example, Agile ways of working include making small, iterative changes to deliver high-quality results with speed. You can also spin up infrastructure when needed, which keeps the cost of innovation down. 

    The Differences Between Agile and Traditional IT Infrastructure? 

    Infrastructure agility is best achieved using modern solutions such as cloud technology. This significantly differs from the traditional approach of having on-premises infrastructure, which cannot be scaled up or down as needed. In fact, on-premises solutions often require extensive upfront capital, while investing in cloud resources works on a pay-as-you-go model to deliver flexibility and elasticity for strategic needs. 

    The conflict between adaptive software methods and predictive methods is another significant difference between these approaches. Development teams follow a comprehensive plan in traditional waterfall approaches, and any changes must go through stringent change control management. Agile requirements, on the other hand, require flexibility, allowing teams to adjust to changes as soon as they occur. This method is suitable for smaller projects that must be performed quickly and efficiently. 

    Benefits of Implementing Flexible IT Infrastructure

    The advantages of having Agile IT infrastructure are numerous. In fact, the adoption of Agile methods not only promotes business growth but is also a great way to reduce costs and improve team performance. By working in sprints, teams can turn around features more often and nurture their value throughout the business. Agile transformation also enables organizations to offer new products or solutions to customers faster, gain early feedback and make changes if necessary, thus avoiding error from the very beginning. 

    Cost optimization is another benefit to consider. With Agile infrastructure housed in the public cloud, IT leaders can expand or decommission resources based on consumer demand. Cloud companies’ pay-as-you-go strategy also ensures that costs are kept to a minimum viable level. For example, maximum limitations can be set for the scaling out of resources. Most importantly, agile working methods eliminate the need for substantial upfront investments, resulting in a higher return on investment (ROI). 

    How to Achieve Agility

    The benefits of Agile transformation are clear; however, the journey to achieving this can take time. First and foremost, becoming Agile requires a clear understanding of what it means and why it is important for your business’ competitive context. Once the ‘what’ and ‘why’ are defined, the ‘how’ becomes easy. The three core steps to achieving this agility are: 

    1. Implementing new methods
      Instead of trying to rework existing IT management tasks and procedures, it is often better to think of new ones as part of the Agile journey. This will ensure that your system’s performance and availability are in line with your core goals. 
    2. Investing in the right tools
      Agile is all about delivering smaller outcomes quickly. To achieve this speed, automating key stages of the software development process is key. There are a host of tools available to undertake this automation, including hybrid cloud solutions that can seamlessly switch between the public and private cloud. A careful selection of the tools that best fit your needs and the correct implementation of these throughout the organization is paramount to achieving success. 
    3. Changing the culture
      To become an agile business, the entire organization requires a cultural change—from how the business discovers a problem to how that problem is resolved by technology teams and monitored in production to enable a faster feedback loop. At every stage of the process, team members need to perform tasks differently, which often requires training, buy-in from the wider team and a collaborative approach. 

    Investment in Agile IT is a smart decision for business leaders hoping to transform their operations, ensure resilience and drive business value. By choosing infrastructure that caters to these needs, you can save money and ensure confidence at critical moments. 

  • Your Tech is Only as Good as Your Infrastructure

    Your Tech is Only as Good as Your Infrastructure

    A few weeks ago, one of my neighbors dug a ditch in his yard, hit a fiber internet line and knocked out my internet for eight hours. There I was, ready to start working, and I was cut off from my colleagues for an entire day.

    That experience highlighted the importance of a good digital infrastructure—both at the office and at home—particularly as the pandemic has ushered in a hybrid work model. When the pandemic hit, organizations that were agile and had a strong digital infrastructure (including processes) were better able to quickly shift to remote work. Those that were not as digitally mature were forced to adapt.

    Eighteen months later, it’s clear that the hybrid model is here to stay, making it even more vital that organizations ensure their workers have the right tech tools to work effectively—and it all begins with a strong digital infrastructure.

    Just Because it’s On a Screen Doesn’t Make it Digital

    Let’s begin with a definition of digital. I recently had a conversation with a business owner who proudly proclaimed, “We’re digital now.” In actuality, all he had done was put a PDF form on an iPad. Once his clients filled out the PDF, he still printed it and put it in a paper folder. That’s what I call an immature vision of digital, and it’s an extreme example of the ambiguity that often exists around the concept of digital transformation.

    It’s not that paper is anathema to digital processes; in some industries (health care, for example) we want paper as a backup. For instance, if I’m a physician at your bedside and the power and/or Wi-Fi goes out and I can’t access your digital records, I need to be able to look at your chart and treat you. So there is a need for paper. But when considering the hybrid or remote work environment, the goal should be to move processes online.

    Digital Infrastructure is the Key to Agility

    As noted earlier, agile businesses are better able to adapt to changes like the move to a hybrid work model. Agile simply means the ability to move quickly and easily, the ability to move fast and make decisions in a fluid way. To do this, we must remove unnecessary steps so we’re able to focus on the end goal and the essential parts of the process.

    This is where a strong (and reliable) digital infrastructure comes in. When you think about Maslow’s hierarchy of needs for digital infrastructure, the foundation is electricity and the internet, and then you build on that. I need computers and hardware and a network, and then I need software platforms and then I need an end-user interface.

    But we’re getting ahead of ourselves; let’s go back to the basics. Once we have reliable electricity and internet, we need to look at other technology that can benefit the remote worker, like upgraded microphones and cameras for all those Zoom meetings.

    These upgrades shouldn’t be an afterthought on the part of organizations; they are at the center of their employees’ hybrid experience and can be another key to success. It’s not enough to send employees home with a laptop and a monitor anymore. Employers must focus on ergonomics (standing desks, good chairs) and the hardware their employees need to be effective at home. If the employer doesn’t provide them directly, they might consider offering a stipend for employees to make the upgrades themselves.

    (Organizations might even consider providing generators to workers who live in rural areas. I have one at my house. And once satellite internet service comes to my town, I’ll have a much more reliable digital infrastructure.)

    Now we can start building on that infrastructure. Start with audio and video communication (Zoom, Teams, Dialpad). Then add chat (Slack, Google Chat) and a good customer relationship management (CRM) system (Salesforce, HubSpot). Where does your data live? Having a great CRM system is critical.

    Using Digital to Put People First

    Organizations ignore the importance of digital infrastructure at their peril. Not only are the days long-gone when employees stayed with a company for 30 or 40 years, but we’re now in the midst of the Great Resignation, where workers are leaving their positions in droves. So it’s incumbent upon organizations to listen to their employees and give them what they need to be successful in a hybrid environment.

    And we’re not just talking about tech. Organizations need to keep employees engaged to really understand the pulse that’s around the organization because, as we all know, the culture and tone of an organization can go ebb and flow. It’s critical for organizations to really listen to what employees are asking for and to be flexible so that they can react and adapt to changing times.

    If they don’t, a ruptured internet cable may be the least of their worries.

  • Does Agile Methodologies Work for IT Infra?

    Does Agile Methodologies Work for IT Infra?

    Recently, I had a fascinating conversation with my old friend Joe–the name has been changed but the conversation is real and unedited–an IT Infrastructure program manager from a large IT service provider.

    After a bit of chit-chat on weather and football, we started talking about infrastructure in a typical large enterprise.

    Joe: I am not sure how agile applies to infra space, I can understand it works well for software development, but not in IT Infra space.

    Me: OK, why do you think so?

    Joe: Well, we have lots of coupling between components, infra projects tend to be big migration or upgrade moves and highly risky. I know many large enterprises in Europe that we work for and many of them haven’t looked at agile in the infra space.

    Forty minutes and couple of beers later…

    Joe: I have to send four reports every Friday afternoon on status, risks, issues.

    Me: Why do you need so many reports?

    Joe: I can’t share all the same info to the client that I share internally. There are some risks that we manage internally. My client wants the info on Jira and confluence. My regional manager wants it on an internal tool (some five-word acronym that I forget!). My account manager wants it as a PPT, as this is an important account and he says this needs to be tracked closely. My global manager wants it on a different tool, inherited from a previous merger as my employer was recently acquired by another service provider.

    Basically, most of my Friday is spent copy pasting information across these reports. Then I spend most of Mondays reconciling the numbers and responding to follow-on queries, and Tuesdays justifying the cost of resources, change in resource costs because many projects are usually in Amber or Red. I think it usually works well if I have a good PMO.

    Me: How many people do you have on the current programme?

    Joe: We have four PMs and seven infra resources on this infra upgrade and migration programme. There is a different provider who looks at the application changes and they have a team of managers and developers etc. The seven infra resources I referred to are also busy with BAU work.

    Me: So, you have seven part time infra people who are the actual doers, one programme manager, four PMs and PMO, client side vendor manager(s) and you are running half a dozen projects.

    Joe: Yes, as you can see, we can’t be agile in infra.

    Me: Why do you need projects? And, why do you need so many of them?

    Joe: What? No projects? Surely, that’s how it is always done! How do we ensure control, governance?

    — Aditya Vadaganadam

  • Reality Check: Bringing Continuous Delivery Dreams to Life

    Reality Check: Bringing Continuous Delivery Dreams to Life

    Every developer shares the same dream: to write a piece of code or app that changes everything.

    Whether it makes your company do things more efficiently, attracts hordes of new customers, simply makes existing clients happier or maybe even changes the world a little bit, that code is what we strive for. Some of us don’t merely harbor that dream; many of us actually achieve that moment of brilliance. For those who have, it’s remembered as a moment of pure joy.

    So, where does this magical process begin? First, you talk to your manager and, if you’re lucky, she or he agrees that it is a fantastic idea and starts to sell it internally. Sometimes the idea is so good that you get the go-ahead on the same day and even get a small team to work on it!

    Then, soon thereafter, reality kicks in.

    You need data, inevitably from applications running somewhere in the cloud and/or some other data from on-premises data stores. You need to interface with APIs, some well-documented, some not. You need some user experience work done, and the standards your company has adopted don’t really match your vision.

    You also need to interface with many of the standard services your company has already implemented because, after all, your app doesn’t run in isolation—you work with existing billing systems, a CRM system, a fulfillment system … and all of them run on servers that can be anywhere. Soon you find yourself fighting for test data, systems to test with and applications and APIs to interface with. Before you know it, you’re banging your head against the wall.

    Fortunately, your teammates are flexible, creative people. And because your internal systems seem to work against you, you go around them. You download a trial version of some testing software; you install a copy of some internal systems on a virtualized test server (if you can find one) and start working with these.

    Since your app needs to be snazzy and snappy, you download some open-source software to help you test the performance on mobile devices. After three sprints, you’re now ready to move your app to an environment where you can start performing real tests!

    Most times this is the moment when the hardest reality kicks in. The copies of the systems you tested with were not up to date. Data has changed. APIs have changed. The real system responds three times slower than the copy that sat on the server right next to you. The data in the cloud has changed. The performance testing tool you used is not available in the official testing environment. … The list goes on.

    This doesn’t even include the difficulties of moving all the components of your new app to different environments. Trust me, this is not a fictional nightmare scenario; it is reality and I see it happen all the time.

    Now, what if you had the test-data generators necessary to create the data you need and a server that ran virtualized services, mimicking all the (up-to-date) external systems you need including the APIs to talk to them—services that would allow you to say, “What if this application responds three times slower when I request data?” or, “What happens if this system suddenly goes down?” What if, when you’re done building, you could simply migrate the app and all the components that go with it to another (test/QA) system with one click?

    Everybody wants to support people with good ideas and turn these ideas into working software without the frustration that very often distracts and demotivates people. To do so, you need to create the infrastructure that supports this. Is it difficult? Not really, the tools to automate services, create test data (and test scenarios) and migrate complete applications from A to Z are available.

    However, just like a great app, this too starts with a dream—the dream of allowing people with great ideas to work on these ideas without the overhead of an infrastructure that allows them to focus on the coding and not on the infrastructural issues; the dream to create a software factory where the creation of the app takes 90 percent of the time and the infrastructural burden only 10 percent, not the other way around.

    If you’re serious about developing software and want to create an environment where the infrastructure allows people to develop and release software faster instead of working against them, find the tools that support it and jump in, because they exist today.

    Enacting this change now and maybe the next time someone comes to you with a great idea you can be confident that they will have all the support needed to get there efficiently.

    — Marcel den Hartog

  • Agile Infrastructure: Because your Infrastructure Deserves Tests, Too

    Agile Infrastructure: Because your Infrastructure Deserves Tests, Too

    Editor’s Note: This post was updated Aug. 4, 2018, to reflect an updated slide presentation at the end of the article.

    Infrastructure as Code is a truly powerful concept whose significance is best described with the words of Adam Jacob, CTO at Chef, in Web Operations: Keeping the Data On Time: “Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.” And so it’s not for nothing that treating infrastructure as code is regarded a key principle for reducing cycle time and maximizing flow in Continuous Delivery and DevOps, respectively. Even if your plans are less bold as you read this article, wouldn’t you agree that consequent validation of what you automate on the infrastructure level — long before it goes into production — would be extremely powerful?

    So, bear with me for a while and please don’t rush head over heels into automation by simply picking one of the established infrastructure automation tools such as Chef or Puppet, getting everyone trained in Ruby, and blindly start to “automate all the things”. If that’s how you do it, then you are most probably doing it wrong. In You’re Doing DevOps Wrong. Automation in the Enterprise., author Alan Sharp-Paul suggests that, before doing any automation, you first have to understand precisely the requirements and how to validate them to gauge success and maintain quality of your automations over time:

    • Are the configuration files in place? Do they contain the right settings?
    • Is this port open? Is that port closed?

    Why Agile Infrastructure?

    Honestly, you and I wouldn’t expect anyone to come up with reliable software merely by choosing an arbitrary programming language and a nifty IDE without having some sort of engineering process in place, right? Likewise, the (automated) provisioning of a solid production environment demands a no less methodical approach. Luckily, Infrastructure as Code enables us to treat the provisioning of infrastructure as well as automating deployments and configuration as an Agile engineering discipline. Although the concepts of Agile Infrastructure are not entirely new, testing against live infrastructure has only recently been facilitated with the consolidation of tools such as Ansible, Chef, Puppet, Docker, Vagrant and Serverspec under the hood of Test Kitchen (see more on that below). Here are some of the key implications of applying Agile software development practices to the infrastructure level:

    Alignment of Devs and Ops

    Agile software development teams are driven by customer demand and aim to produce outcome in short, regular intervals. Enabling IT Operations and Infrastructure departments to work in small iterations and react to changes quickly allows them to align with and effectively become driven by software development. The outcome of these joint efforts will be both working and deployable software at the end of each iteration.

    Fail Fast: Feedback Loops

    Executing infrastructure tests as part of your Continuous Delivery build pipeline (before an application is deployed and long-running tests are executed) establishes another important feedback loop that enables you to “fail fast” and get the right people involved. The underlying principle is simple: by expressing your intentions twice — once in the code and once in a test — you’ll know you’ve caught a bug whenever these assumptions don’t match.

    Regression Safety

    Believe it or not: whether you are using Ansible, Chef, Puppet or any other — you’re running on code! Their respective issue lists are full of unresolved issues of various severities with new issues coming in regularly. Having a sufficient safety net of tests for your infrastructure in place allows you to quickly identify bugs as they creep in (from either side) and protects you against unwanted regressions. After all, a bug in your infrastructure can be very hard to track down and can be much more severe than a bug in your application.

    Refactoring

    Code refactoring becomes a breeze when you have tests in place that immediately alert you when you broke the desired state of your infrastructure (and all you wanted was to make your code simpler and more maintainable). This is invaluable when you want to recompose your existing infrastructure from 3rd-party components offered on public hubs such as Ansible Galaxy, Chef Supermarket or Puppet Forge, and especially when you are migrating away from your existing automation stack.

    The Red, Green, Refactor Cycle of Test-Driven Development

    Test-Driven Development (TDD) is a popular software development process that involves writing code in short, repeating development cycles with the goal to enforce good design and enhance confidence. While it is certainly no silver bullet and has been controversially discussed in the past, the Red, Green, Refactor Cycle, which is at the heart of TDD and whose principles I want to quickly summarize here, hopefully gives you some inspiration on how to incrementally build up your infrastructure:

    1. Red: Understand the requirements and the state you want to implement. Then think about how to capture this state in a test. Implement the test, then run your entire test suite and see the added test fail — and if it doesn’t, something is really wrong.
    2. Green: Implement just enough functionality to make the test pass. Don’t care much about readability, simplicity and design for now — just make it work. Run your tests again and watch all tests pass. If they don’t, either fix your test or your implementation, or take a step back (revert to a point in your code that’s known to work) and start over with a smaller increment.
    3. Refactor: Now that your tests pass, improve your implementation and make sure, by running your tests again, that you didn’t break anything. Once you are done refactoring, start the cycle over again.

    Keep in mind that each repetition of the cycle refers to a small increment. In terms of infrastructure, such an increment could be the installation of a user, a package or the placement of a configuration setting. When you arrive in a spot where you broke something, you can easily revert to a point in your code that’s known to work. Leveraging such practices really makes the difference between Infrastructure Automation and Infrastructure as Code, as described in Infrastructure as Code – Automation Is Not Enough by Keith Morris.

    Test Kitchen, Terraform, AWS and awspec

    Now, how to get there? Test Kitchen is an easily extensible test harness that allows you to test your code written in Ansible, Chef, Puppet (and others) on various cloud providers, virtualization providers and operating systems with tests written in a variety of test frameworks.

    In the following presentation, I give hands-on examples for you to quickly dive into the topic of using Test Kitchen with awspec as a framework to test Terraform deployments on AWS: