devopsy.kinsta.cloud

Tag: Agility

Four Steps to Balance Agility and Security in DevSecOps

Companies are under immense pressure to deliver updates, new features and security patches rapidly to remain competitive. Meanwhile, the rise of sophisticated cyber threats demands security to be integrated from the start of development, not as an afterthought. This is where DevSecOps comes into play, embedding security into every phase of the software development lifecycle (SDLC) without sacrificing agility.

While the benefits of DevSecOps are clear, challenges remain. In today’s digital landscape, agility is critical. Amazon deploys code every 11.7 seconds to remain competitive. But how can companies achieve this speed without compromising security? With the right strategies and tools, organizations can achieve fast, secure delivery pipelines.

I recently spoke at All Day DevOps (ADDO) about how practitioners can maintain agility while embedding security at the core of DevSecOps processes. The answers lie in automating repetitive tasks, establishing feedback loops and creating a culture where development, security and operations teams collaborate closely.

1. Automating Security for Speed and Consistency

Automation is the cornerstone of agile DevSecOps practices. By automating security tasks, organizations can maintain the speed and consistency required for continuous delivery without manual interventions slowing down the process. Automation allows security testing to happen early and often in the development cycle, enabling developers to detect vulnerabilities before they escalate into critical issues.

Tools like OWASP ZAP and Burp Suite can be integrated into continuous integration/continuous delivery (CI/CD) pipelines to automate security testing. For example, LinkedIn uses Ansible to automate its infrastructure provisioning, which reduces deployment times by 75%. By automating security checks, LinkedIn ensures that its rapid delivery processes remain secure.

Automating security not only enhances speed but also improves the overall quality of software by catching issues before they reach production. Automated tools can perform static code analysis, vulnerability scanning and penetration testing without disrupting the development cycle, helping teams deploy secure software faster.

2. Implementing CI/CD Pipelines with Security at the Core

A robust CI/CD pipeline ensures that security checks are integrated at every stage of the development, from code commit to deployment. For example, Facebook has embraced CI/CD by deploying code twice daily, cutting time to market for new features by 50%. By embedding security into these pipelines, Facebook minimizes the risk of security vulnerabilities slipping through.

Best practices for secure CI/CD include frequent code commits, automated testing and continuous monitoring. Tools like Jenkins, GitLab and Azure DevOps offer integrated security features that help enforce these practices. For instance, Atlassian’s use of secure CI/CD pipelines for Jira has helped reduce their average release cycle by 40%, while also enhancing security at each stage of development.

3. Continuous Feedback Loops for Agile and Secure Development

By gathering feedback from various sources, including security monitoring tools, user data and security incidents, teams can identify issues early, iterate quickly and improve both security and performance. Google’s continuous feedback system, for instance, has resulted in a 30% improvement in user satisfaction. Similarly, by incorporating security insights into feedback loops, organizations can adjust their processes to respond to new vulnerabilities or threats.

Automated feedback mechanisms can notify developers of security flaws in near real-time, allowing rapid resolution of issues without delaying delivery. Establishing robust feedback loops ensures that security is not a one-time event but a continuous process that evolves as threats and requirements change.

4. The Role of Collaboration in Balancing Agility and Security

Cross-functional teams composed of developers, security experts and operations personnel must work together seamlessly to identify and resolve security issues without slowing down the pipeline. Breaking down silos between development and security teams fosters a culture of shared responsibility. Google’s site reliability engineering (SRE) teams exemplify this approach, reducing downtime by 40% through close collaboration between developers and operations. By bringing security into the fold, organizations can ensure that security is addressed proactively, not reactively.

Promoting a culture of collaboration also means investing in communication tools like Slack or Microsoft Teams, which enable fast, transparent communication between teams. Regular stand-ups, retrospectives and joint planning sessions can help ensure that security is embedded in every decision made by development teams.

The Path Forward

As organizations look to the future, artificial intelligence (AI) and machine learning (ML) will play a crucial role in enhancing both security and agility. AI-driven security tools can predict potential vulnerabilities, automate incident response and even self-heal systems without human intervention. This not only improves security but also reduces the time spent on manual security reviews.

AI-powered tools can analyze massive amounts of data, identifying patterns and potential threats that human teams may overlook. This can reduce downtime and the risk of cyberattacks, ultimately allowing organizations to deploy faster and more securely.

Balancing agility and security in DevSecOps is achievable with the right mix of automation, collaboration and continuous feedback. By embedding security into agile processes, organizations can deliver software that is both fast and secure, meeting the demands of today’s fast-paced tech environment. As AI and intelligent automation continue to evolve, the future of DevSecOps holds even greater potential for faster, more secure software delivery.

November 6, 2024
The Path to App Modernization: Benefits, Pitfalls and the Route to Success

There are many reasons an organization may find itself on the path to considering the risky journey of application modernization. It could be to gain an edge or to build a more competitive positioning, or a business could have a legacy system running on infrastructure that is no longer viable, leaving them no other choice. But the conundrum for organizations still resurfaces when considering app modernization; they must select one of these two routes: Either “the failure rate is high, and failure is simply not an option” or “Everyone is still doing it, so let’s forge ahead.”

The Benefits of Choosing Application Modernization

Whether an organization chooses this path out of necessity or ambition, modernizing an old IT environment can deliver several benefits, ranging from reducing outdated hardware and software to creating new value through innovation. Specifically, the key benefits are:

● Reducing technical debt and improving the underlying infrastructure: Improved security, operations, reliability and scalability.
● Decreasing expenses: Lowering the cost spent on expensive hardware and software improves the utilization of resources, thereby decreasing the total cost of ownership of technology operations.
● Accelerated time to market: Modernized IT and product development gain value from technological improvements that decrease the time it takes to develop and deploy new products and services.
● Agility in the market: Modernization enables an organization to react to changes at an accelerated rate, providing a competitive edge in the market.

Choosing the Best Path to Application Modernization

There are different paths to modernization, each with its own focus. On the one hand, there’s the infrastructure aspect of building your platform engineering practice versus adopting a service approach with a platform-as-a-service (PaaS). On the other hand, there is the actual process of modernization with options like refactoring, re-platforming or rewriting your systems, either in-house or through outsourced services. It ultimately starts with modernizing the relationship of the application with its infrastructure and changing some assumptions.

Once you have a baseline, running everything else should come from a cost-benefit analysis. A scalable, well-managed monolith is valuable despite its age. Ensuring horizontal scalability and a robust backup strategy are key to effectively managing mutable data.

First, understand the blockers in your current implementation that would complicate a shift to the cloud. Or identify where the result may not deliver any value.

There are very common anti-patterns that remain anti-patterns, whether on the cloud, running on managed hosting or on-premises. Identifying them allows you to start absorbing technical debt regardless of whether a move to the cloud happens as intended.

Anti-patterns to look out for are:
● Weak separation of code and configuration: You want to be able to run many parallel instances of each application as separate environments. Telltale signs are hard-coded URLs and service credentials. The dependency is the capability of running ephemeral preview environments that are quick to launch and quick to destroy, such that you know that you are “cloud ready.”
● Weak separation of the read/write domain from the read-only domain: In a cloud deployment, you want a build step that creates immutable artifacts that are not modifiable in production, and you need to know where all the actual data resides. Older applications tend to “believe” they own the whole disk.
● Manual configuration of services: You should be able to run “stock” services without any manual configuration in case the need for a specific database configuration arises and signals the likelihood of an application issue that requires debugging.

Simply packaging a Docker container or a VM image and deploying to an IaaS won’t create any benefit and only increases costs. The first step to success is a thorough clean-up and update of the documentation to start the process.

The one basic rule to follow is the ability to run an arbitrary number of instances of every element. Achieving this will allow everything else to flow. There is no need to rush to transform all Crons into “separate workers” and break the monolith into microservices. But the proof that it is possible now exists.

The Best Approach to Application Modernization: In-House or Outsourced

A mixed approach between in-house and outsourced is often optimal. There are many elements to consider. If you have a minimal in-house understanding of what the cloud imposes as constraints, you may be tempted to go for the simplistic lift-and-shift approach. Outsourcing everything can lead to huge amounts of lock-in.

There are ways to cut corners that could simplify and accelerate the initial project, but this could increase the costs down the line. There needs to be a level of abstraction where using a PaaS is a winning proposition and can provide quite a bit of abstraction at no cost.

Without control, the project may end up as something that “runs on the cloud” without the actual benefits. But there are many ways to do that.

The Right Mindset Will Help Avoid Pitfalls Along the Way

By neglecting constraints and skipping the necessary preparation, the costs may escalate. Running big chunks of hardware continuously versus using small ephemeral resources as needed typically leads to significantly increased costs over time. Full rewrites often go wrong when trying to obtain all the benefits immediately.

A simple four-step approach for success is:

● Start with modernizing the relationship of the application with its infrastructure and changing assumptions.
● Identify and address the blockers in the current implementation–this makes a shift to the cloud less complicated and enables a smoother transition.
● Set a baseline that allows everything else to run from a cost-benefit analysis. Ensure horizontal scalability and implement a robust backup strategy to effectively manage mutable data.

Accepting that app modernization will be a journey and that the initial implementation is a slightly more scalable and resilient version of the original. This is often a better mindset that leads to a more effective process.

September 14, 2023
Some Change is Bad
Some time toward the end of the year, I start considering the volume of change we, as practitioners, have been under for … literally years, even decades. And I start to try and think of ways to keep you all from drowning in change. And then I write something that I hope helps you all focus on good change, and keeps moving your environment forward.

This year I’m going to say “consider the reasons for the change.” I will attempt to find examples that do not require mentioning a specific product or vendor, so apologies if these read a bit convoluted as I attempt to illustrate this point without castigating.

There are three basic reasons that a market or marketers want you to consider a change. There are, of course, variants and cases where it is a bit of this reason and a bit of that, but most demands that we change what/how we are doing things can be lumped into “mostly one of these”. They are:
1. A great idea that is really a game-changer for some subset of the market.
2. A shifting of who is in control.
3. Locking customers in or expanding revenue.
All of these happen at the vendor/project level, and all of them happen at the market level.

Number one is best illustrated by any of the waves of server virtualization that have come through. From virtual machines to containers, each has solved problems and changed the way we do business. Notably, I’m only talking about server virtualization efforts here. Most of the other virtualization attempts have really not fit the “great idea that is a game-changer” category, though some have limited usefulness. Personally, I think the new version of storage virtualization will be in the game-changer category but am waiting to see it in use.

Number two is one to watch out for and is most obvious when big-name OSS projects are forked. It is rarely about the technology being implemented (after all, a fork is a copy of the original; at first it is not at all about the technology), but rather about who is calling the shots. There is a bit of this in every public cloud vendor implementing their own version of container management (though this example is more about lock-in, in my opinion).

Number three is multi-pronged. If your vendor went from selling you hardware or software to selling you a service, they want that recurring revenue and they want you to be linked into that service so deep that you can’t walk away. The much-reviled 1990s mantra of “embrace and extend” is the poster child for this kind of change. There might be a value-add in there somewhere and sometimes the added functionality makes the move a no-brainer. Often, though, the change is simply to the vendor’s advantage, not their customers. As most major Linux distros have shown, open source is not immune to this one, as most of them are making OSS users the de facto beta testers for their paid offerings.

None of this is to say that the change in front of you is bad—even if the reason it was originally spawned is bad. It is reminding you that, after a constant stream of change, we’re more open to it than maybe we should be and you should remember the only important thing about new changes—do they make our environment more secure, faster, more agile? Everything else is just noise. Yes, all the cool kids are switching to coding in [insert flavor du jour], but does it offer your organization anything new? Yes, it seems everyone is using [insert current CI/CD flavor], but does it address the weaknesses of your current toolchain?

You all are nailing it. Keep doing it. And don’t be afraid of change, but make sure you know if that new OSS database system is really new, or just a lot of installing the same code under a slightly different name. Because someone didn’t like the new owners.
November 24, 2021
Next Up: Portable CI

One thing that we’re very good at in IT is breaking new ground, coming up with ideas that work astoundingly well, getting broad adoption, then standardizing them for interoperability. When a new technology (looking at you, cloud) has problems with standardization and interoperability, we find a way around vendors’ reluctance to give you freedom of choice. For cloud, for instance, we found another great technology – containers – that greatly limits our lock-in to a given cloud vendor’s fare. Of course, whether standards or workarounds are the answer we arrive at, there are always wrinkles. Vendors are certainly not motivated by interoperability; they want your regular cash infusions, and interoperability could be more of a drain on them than a feed of new customers. Particularly in today’s environment, where vendors sometimes think that doing “to” customers is an acceptable substitute for doing “for” customers. We have to work around things like “embrace and expand,” which is still very real, and deploying containers to cloud A versus cloud B still has a bit of vendor-specific work, but we have enough to get it done.

As continuous integration (CI) has become critical to an increasing number of organizations’ IT processes, the time has come to do the same with CI tools. Standardization is a good first goal, but it is more difficult here than in many areas, because the topic is so broad. An app might be built in one tool and tested in another, or it might be built via the use of shell scripts while tested with a UI tool, etc. It is not an easy solution to build, but it is an idea whose time has come – particularly with the cloudification of the space. We now have full-on CI systems that are in the cloud, and which hook you in with custom instructions. We’ve already had one large DevOps vendor essentially tell their entire user base, “We’re moving you to the cloud, unless you pay these inflated fees,” and others that never offered options for traditional architectures at all.

Yet, we know apps move from in-house to cloud (and though it is uncool to mention, move back), and organizations are motivated by cost containment and mobility more than by what their chosen vendor wants them to do.

So, it is time for some bright company or OSS team to put together a standard and a tool that implements said standard. It will be a lot of work, to make portability between CI tools that came from widely disparate roots – some from build, some from test, some even from deployment. But we’ll be needing it. A while back, everyone was a Puppet shop. Now, it seems, everyone is an Ansible shop. In simple terms, everyone will inevitably be a [something else] shop, because nothing lasts forever. So, a tool providing CI mobility between tools will definitely have a market – smaller today, but eventually large. We don’t need Yet Another CI Tool, we need that portability.

I’m sure it’s coming. History does offer glimpses of the potential future, and we’ve seen this cycle before. I’m just saying, the time is now, not five years from now. We can target the OS of our choice and the cloud vendor of our choice, using containers to simplify the differences in host OS/vendor. The ability to use the CI tool of our choice is the logical next step.

I haven’t heard of a project or company working on this yet; if you have, drop me a link in comments or email (I prefer comments, so others can look at your suggestion too, but whatever works for you), and I’ll take a look. It would be cool to support this kind of effort, when it eventually comes about.

April 29, 2021
DevOps: Driving Innovation With Old Habits

DevOps can help drive cost-efficiency, greater productivity and innovation

When software development and IT operations merge and work in a state of harmony, they create a flow that we call continuous product delivery. Ideal for project managers, this flow is the elixir to innovation and enables the agility needed to respond to changing market requirements. It also creates currents of speed, proactiveness and integration within enterprises. However, asynchronous code updates, inadequate IT infrastructure, siloed functioning and inefficient processes can hinder this flow.

In 2009, Patrick Debois and Andrew Clay Shafer devised a framework to break such barriers and coined it “DevOps.” Over the last decade, DevOps has garnered many followers and fans, including myself. Product managers worldwide rely on DevOps to enhance performance, accelerate time to market and innovate with agility. DevOps is more critical today than ever before—when nature mandates a new order of remote working, product managers must rely on DevOps to catalyze innovation and sustain continuous product deployments and updates.

Yet, not all enterprises that have adopted DevOps have unearthed innovation like that of Dyson, which created a new type of ventilator in a mere 10 days to help the UK government scale COVID-19 treatments. Nor have they been able to match the frontrunners of innovation such as Google and Amazon that can deploy code thousands of times per day, compared to low performers that deploy code only about four times per day. The obvious question on everyone’s mind is, “What are these heroic innovators doing differently with DevOps?”

Driving Success Through DevOps

While business executives are aware that implementing DevOps drives business innovation, most are not aware of the old habits that remain, causing unnecessary hiccups within the application cycle and business transformation. As the way forward, organizations must tweak their approach to DevOps to be able to reap more significant benefits of business innovation. They must:

Ensure speed does not outpace stability

Today’s digital-first world has swept through every enterprise. However, to keep up with the rapid dynamics of the digital tide, enterprises need to weed out monolithic architectures and manual processes to turbocharge software development and deployment. Automating the deployment process with the help of microservices and cloud can help enterprises gain speed in software deployments and swim the tide of customer experiences. Speaking from experience, this is a privilege that has allowed me to witness how DevOps practices have enabled enterprises to crunch deployment times from weeks and days to just a few minutes. Needless to say, innovation depends on speed: The faster an enterprise deploys a novel solution, the higher its chance to claim the prize of innovation.

A word of caution here: Many enterprises that have neglected quality and stability while accelerating speed drown in a vortex of defects often. When pushing out a product or an application 30 times faster than the traditional model, enterprises must consider its stability, too. Cloud infrastructure plays a vital role in helping enterprises achieve both stability and speed. On-demand self-service, networks that cater to multiple devices, high scalability and analytics are some of the primary advantages that enable enterprises to deploy faster without impacting the core.

Losing stability for the sake of speed can cause organizations to regress instead of leaping forward. In recent times, British Airways has been in the news for repeated issues in its IT infrastructure’s stability. It has had to cancel several flights and inconvenience passengers because software upgrades and incidents have caused its infrastructure to fail. Enterprises must consider these four metrics—lead time for changes, deployment frequency, time to restore service and change failure rate—to receive the value of their DevOps investment.

Make security equal to agility

The pandemic-driven remote working has seen the video communication solutions provider Zoom soar to 300 million active monthly users last month. The brand showed great agility in meeting the surge in demand but became vulnerable to cyberattacks—500,000 Zoom passwords were available for sale in the dark web’s crime forums last month. This is an excellent example of how security is usually an afterthought when compared to agility; not prioritizing security in the DevOps cycle can place teams and their organizations at significant risk, creating vulnerabilities and exposing organizations to bad actors.

In my experience, putting security checks in place early in the DevOps process can help enterprises shift left more effectively. As a first step, security and development teams need to communicate better through the continuous delivery flow. Security teams need to play more proactive roles in foreseeing risks in innovative solutions and routine software updates. Leaving security for the last will only force organizations to be reactive versus proactive.

Build collaboration, not silos

Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change. DevOps is a process that provides tools but it is also a philosophy that promotes collaboration among teams in software development. It catalyzes an ecosystem that encourages high collaboration and information-sharing. In a DevOps culture, failure is not shot down but leads to inquiry that drives solutions. Seamless information flow is the critical outcome of a DevOps-driven organization. Proper information flow is timely, answers questions and is understandable while needing the support of tools and technologies to drive success.

The General Motors Freemont Assembly line has been a great case study of how poor workforce culture can cause an enterprise to shut down. As one of the largest automobile factories in the United States, the manufacturer had to shut shop in 1982 due to rising losses attributed to an unruly workforce that was protected by a strong union. Within the next two years, the same factory was re-opened in collaboration with Toyota Motors, and it was called NUMMI.

NUMMI hired up to 85% of the old workforce of GM’s Freemont assembly. The difference was the Toyota culture–one that focused on learning and improvement and set a framework of how leadership interacted with and inspired teams. This change was fundamental in driving success for NUMMI, which reduced the time to manufacture a car to 20.8 hours in 1986—a drastic improvement over 43.1 hours in 1978.

At a time when we are witnessing unprecedented disruptions to supply chains, manufacturing and employment, enterprises need to deep dive into functioning to explore new opportunities for cost-efficiency, greater productivity and innovation. DevOps can help achieve these and build the foundations for continuous innovation. Investments in automation, cloud and culture will help enterprises realize the continuous flow of product delivery and innovation. The wave of innovation in the new normal will be propelled by the forces of time-tested practices and new next-generation approaches to enable enterprises to shift-left.

September 1, 2020
Can NetOps and SecOps Finally Get Along?
For years, the very definition of NetOps and SecOps has involved friction and even contentious relationships that make their respective jobs more difficult and lessen their efficiency and effectiveness. Much of this conflict originates from having charters that are seemingly in opposition to each other. At the surface, NetOps stands for connectivity, openness, speed and capacity. In contrast, SecOps comes across as binary opponents, posting for far too many regulations with segmented connectivity and a more or less closed or impaired environment.

The truth is, however, both groups have the same goals:
- Ensuring business operations and agility.
- Protecting resources.
The network is only important in its ability to connect users, systems, applications, information or data and other resources, ensuring effective business operations and agility. The network is means to an end, and not necessarily an end to itself. In a somewhat similar way, security is also not an end, but, rather, the means to an end. Security exists to protect these same users and resources. It’s all about the users and resources being able to run business operations effectively and with the agility and flexibility necessary to give it strategic advantages. Reflecting on this perspective may help NetOps and SecOps realize that they are not so far apart from each other.

Both NetOps and SecOps struggle with many of the same issues. Both are usually overworked and understaffed, responsible for critical components or aspects of business, face constantly changing environments and challenges and slowed by cumbersome processes and a lack of agility. Because of these things, NetOps and SecOps are largely in the same boat, sharing the same storm.

The lack of agility is a particularly important issue, as new technologies and techniques are constantly being developed that enable security teams to stay ahead of—or at least keep pace with—attackers. Motivated attackers tend to be far more innovative that defenders and can use anything at their disposal to accomplish their goals. Entire cybercriminal supply chains exist to provide attackers with applications, utilities, routines and even services to conduct their campaigns. These things can and will be used against defenders.

On the other hand, deploying a new security solution on the network is generally a long, involved, cumbersome process. Even changing solutions involves considerable effort. Sometimes the rules or process gets invented along the way, compounding the difficulties. Additions or changes to the network involve tedious review processes mostly dictated by NetOps. The NetOps team also faces some of these same difficulties in adding or changing network management or monitoring solutions.

While a careful review is warranted, current processes are too time-consuming and involved. One significant improvement can come from NetOps and SecOps coming together with an established and codified approach for network changes or additions. Getting issues out on the table for discussion is a great start. This means more collaboration and a joint learning cycle on short- and long-term organizational objectives. Both groups need to understand and appreciate the concerns of the other and realize their common ground. Prioritizing issues and agreeing on a fundamental set will ease the overall process, reduce unwarranted fear and antagonism, and eliminate much of the inventing the process on the fly.

An emerging approach seeks to establish a centralized deployment point for both networking and security solutions with pre-established rules agreed upon by both teams. Ideally, many of the concerns can be addressed or mitigated by hardware and software designed to enforce policies or rules, provide failover as necessary, prevent performance degradation or add to the attack surface. These can allow solutions to drop into the network while offering guarantees of performance or availability.

Streamlining deployment of shared management will result in much-needed agility and also boost efficiency and overall effectiveness. It will also lessen the typical tensions or outright opposition.

NetOps and SecOps are much closer to each other than either realizes. Their shared guardianship of users and resources can benefit from joint discussions, plans, tools and policies. Not only can they better accomplish their own charters of connecting and protecting while providing agility and flexibility, but they also can become far more efficient with their operations. They need each other, and their organizations need the vital contributions from both. As typically said in security jargon, “A chain is only as strong as its weakest link.” The new paradigm of security-driven networking is about preventing weak links through the collaboration and synergy between NetOps and SecOps.
July 8, 2020
Review, Review, Review

Ossification is an issue in IT, and always has been. It is borne largely out of staff and management knowing what to expect from existing software/infrastructure, and the deep product knowledge that allows teams to make existing systems do what is needed. But this becomes a series of rocks that the ship of progress smacks into.

Contrary to popular belief, DevOps and other new methodologies are not immune to this problem. Quite the contrary, we’ve spoken with people that say “We’re a Jenkins shop,” which sounds exactly like “We’re an Oracle shop” of a decade ago. The wave just ushered in new tools, it didn’t change tendencies. OK, it did more than usher in new tools, but it didn’t change tendencies.

So, it’s time for a friendly reminder: Review what you are doing, review cloud usage, review tools in the toolchain, review methodologies, review security posture (which has suffered in this environment for far too many shops) and review customer satisfaction.

Many organizations used the push of Agile and DevOps to update stagnant parts of the infrastructure and development toolsets. Don’t let them become stagnant again. Just as you don’t want change for the sake of change, you don’t want to stay with one tool or methodology just because it is comfortable.

This isn’t some easy task that I ⁠— or anyone else, no matter how much they try to tell you differently ⁠— can dictate to an organization. There isn’t a handy list, because no two organizations are exactly the same. Not in toolsets, not in culture and not in appetite for risk. The only thing we can offer is guidance to look closely at where you are, what’s available in a given area ⁠— Application Release Orchestration, for example ⁠— and evaluate the available tools just like you were making a fresh choice and did not have a tool in place. Then do the same for processes. Is this the best process for what we’re trying to achieve? Are there tweaks we can make to it? Should we completely change the process to take in changes in environment that have happened since we adopted this process?

Finally, if you don’t have someone responsible for monitoring cloud costs, appoint someone. Get them the tools, help them understand where the money is going and what cloud-based server usage is. Could these servers be spun down outside of business hours? Could we follow the sun better by staggering cloud data centers in which cloud servers are active, rather than hosting them always in one location or leaving them on 24/7 in multiple locations? Is one team using a cloud feature no one else is? If so, how does it apply, and are the other teams not using it because they don’t need it, or is there some other solution they’ve adopted?

Basically, question everything. We’re launching a new project that will be a simple dynamic app. Make a few selections from a limited list, get a summary of what you should do and why. It is all really quite simple. Should we host in a web page or make it a standalone mobile app? If mobile app, what tools for development and what targets? Integration of Git — should it be local or on one of the big providers? Do we want any team member to trigger builds on commit or do we want someone managing branch merging before-hand?

These are all things we already do on other projects, but we’re digging in and seeing what could be better. What could we improve, and what would the rewards for that improvement be? It takes a bit of time and some discussion. We’re confident we’ll burn through it in the next day or so and come up with a plan for development and architecture that best suits the app, but is informed by where we’re at now. It’s been a fun exercise, to be honest. If nothing else, it gave us a strong reminder that any given cloud provider’s “simple” pricing is not that simple, and we need to pay more attention to app characteristics versus fees.

You’ve rocked it this far, even kept the lights on during the great shift to working from home. Don’t stop improving the environment though, find innovative ways to make it better and keep clipping along.

June 11, 2020
Rigidity or Agility During Change Processes: You Do Have a Choice

As most who work in service management, on an IT team or as a member of the service desk understand that change management can be a rather rigid, shall we say, still process. Do you want to make your change implementations more agile? There are different ways to go about this. In this piece, I plan to discuss how to implement a single change in an agile way, and how to make all your department’s future changes more agile. Let’s first begin with how to make the implementation of a single change more agile.

Describe Your Goal and Preconditions

Ideally, when necessary changes are required, you shouldn’t need to complete a full change request form when submitting the request. The description should only contain basic information regarding the change. Most importantly, what must be included are your goal and the required preconditions.

Here’s an example: You receive multiple calls about a coffee machine breaking down, or an email server running slowly. As a service desk representative, you’d likely prefer not to receive and handle a bunch of calls about the same problem, but you do want your customers to be able to know whether or not a problem has already been reported and is being dealt with. Your team’s goal, then, is to show your customers that a ticket already has been submitted for the problem and that you are working on it, but you also want to make sure your customers don’t get to see the private information of other customers—that would be one of your preconditions.

Apart from your goal and preconditions, there’s not much more you need to know when you get started with a change.

Check Regularly if Your Change is Still Meeting the Pre-Set Goal and Preconditions

Implementing changes according to the waterfall method can mean there’s a chance that, when done, the solution doesn’t meet the customer’s needs. The waterfall method likely means you want to execute your plan without alterations along the way. Under this model, there’s no room to adjust to new situations even if you need to make changes. You may find new information about what your customer really wants, or there could be new technologies on the market providing a better solution to your perceived problems.

So, while you’re designing and implementing a change, regularly check to see if what you’re doing right now still contribute to the original goal, and whether you’re still meeting the pre-conditions. As you know, agile processes lets you make adjustments along the way. But perhaps you’re already past the point where you could have made a change. If that’s the case, in an agile workflow, you can change course and simply work the change.

Involving Others in Your Change

Once you’ve got an idea of how you want to implement a change, make sure to include your team’s experts so they are able to take a detailed look at your plans and determine the impact of the change on other applications and hardware. Additional points to consider include analyzing any change that may lead to security risks.

When following the agile philosophy, it’s better to let your team come up with its own solution, but if the team figures everything out for themselves, you want outside members to perform the quality check. As the saying goes, freedom is not free. For IT teams, the freedom to come up with a solution means they also must be responsible for determining whether the solution will work as planned.

Run As Few Changes As Possible at the Same Time

IT departments almost never work on more than one change at a time, even those that are small. Unfortunately, there can be too many changes to the handle. To keep the number of changes in check, limit the number of changes that need to be undertaken at any given time.

Doing so makes it easier to predict the duration of changes. Working on fewer changes at once means you’re working with fewer variables, so you can better predict when you’ll finish a change.

Also, the fewer tasks in operation, the more likelihood of the service being higher. If you’re able to focus more on the change you’re currently working on, you don’t make as many mistakes. Finally, with fewer tasks you’re able to focus on your work and quickly generate results. Visible progress is one of the most important factors that determine happiness at work and getting things done in a timely manner is more motivating than constantly toiling on a number of different things with nothing ever getting finished.

Managing Changes vs. Incidents

When there’s a constant flow of incidents coming in, your service desk employees must make the decision about your team’s priorities and what they are going to be. For example, do you want to guarantee a maximum time for required changes? To meet outcomes and objectives that are set by this team, you must dedicate a set amount of time that each team has to spend on said changes. This means you must be able to accept that some of your reported incidents won’t be addressed immediately.

Alternatively, if it’s more important to solve incidents quickly, you need to accept the time required to implement these changes, and an understanding that your team won’t be able to handle new changes as quickly as you might hope to. Change requires time, even if time to solve incidents is your biggest priority.

— Nancy Van Elsacker Louisnord

August 30, 2018
Break the Rules and Win at Digital Transformation

The rules of the game have changed.

In today’s digital world, it’s not about the big eating the small. It’s the fast that beat the slow and the nimble that outmaneuver companies constrained by old systems and business models.

What’s more, the finish line is always moving. The rapid pace of innovation and disruption means businesses must continuously transform themselves to stay ahead of competitors.

The takeaway for CIOs: Speed and agility are the name of the game.

IT must respond faster than ever to shifting business needs. To succeed at digital transformation, companies must rethink how they design, build, deploy and source enterprise applications. They must adopt new approaches that accelerate delivery and anticipate, even bake in, ongoing changes.

It’s time to update the IT playbook. Here are five best practices from digital leaders that are breaking with the past to deliver a successful future.

Accelerate and Iterate Software Delivery

Digital leaders outpace their rivals by adopting methodologies and mindsets that shorten software delivery cycles. They’re also really, really good at rapid, iterative change.

Shift to Speedier Methodologies

Digital leaders rely on Agile development methods—short sprints, scrum teams and user feedback loops—to accelerate the design and development of new applications. With its emphasis on rapid iteration and continuous improvement, Agile methodologies are a proven way for companies to churn out new innovations quickly. Studies show Agile approaches average 50 percent faster time-to-market than waterfall ones.

DevOps is also a catalyst for speed. Automation and tighter collaboration between development and operations make it easier to put new code into production. Led by such companies as Facebook, Google and Amazon, the world is moving away from “that 10-year-old solution everyone’s afraid to touch” to flexible platforms that are updated multiple times a day.

Adopt an Agile Mindset

Of course, being agile requires more than just new methodologies. It also demands a willingness to take risks, learn on the fly and adjust continuously. Digital leaders don’t just respond to change; they embrace and design for change.

Digital leaders test and then invest. They fail fast and then swiftly course-correct. The most successful experiment rapidly and incrementally so if they do stumble, they fall from the first floor, not the 10th. Digital leaders also think big. They don’t just digitize current processes. They completely re-imagine business models and technology systems—as Pitney Bowes did with its transformation into a digital commerce powerhouse or as GE did with its launch of the Predix industrial IoT platform.

Adopt New Application Architectures and Infrastructure

Digital leaders are building in flexibility with new application architectures and deployment models. They’re leaving legacy systems behind as they take to the cloud with microservices-based solutions.

Move to Microservices

Monolithic applications are hard to change, costly to maintain and ill-suited to today’s dynamic business environment. That’s why digital leaders are moving to an agile, microservices-driven architecture. Converts include Netflix, eBay, Amazon, Twitter, Gilt, Liberty Mutual and the UK Government Digital Service, to name just a few.

Assembling applications from small modular services—each a self-contained building block—allows digital leaders to transform quickly and at scale. They can mix and match services to fast-track new digital offerings and processes. They can tweak and scale services to adapt to changing business models and customer expectations. And they can push innovation across the enterprise by reusing services—all without adding armies of developers or getting locked into any one technology.

Step Up Cloud Migration

The cloud is increasingly the preferred foundation for digital transformation. Digital leaders gain speed and agility by plugging into on-demand services and computing resources. They short-circuit long design and procurement cycles; focus on innovation, not infrastructure; and deliver differentiated capabilities and customer experiences at a fraction of the time and cost.

Digital leaders are betting big on the cloud. According to IDC, at least half of IT spending will be cloud-based by 2018, reaching 60 percent of IT infrastructure spending and 60 percent to 70 percent of software, services and technology spending by 2020. Organizations across industries—such as Nike, Xerox, General Mills, Liberty Mutual, and the U.S. federal government—have migrated mission-critical workloads to the cloud to support new, more digital ways of doing business.

Use Novel, Unexpected Sources of Innovation

Digital leaders rely on open-source innovators and third-party collaborators to shorten development cycles. They’ve also abandoned long RFPs in favor of shorter, more effective proofs of concept (POCs).

Embrace Open Tech with Open Arms

Open technologies—including open source, open standards and open APIs—dominate the digital landscape. According to a study by North Bridge and Black Duck, open source software makes up more than 50 percent of the typical enterprise and application stack. Digital leaders including Ticketmaster, Box, eBay and Goldman Sachs rely on open-source software to speed solution delivery and draft off the innovations of millions of developers worldwide.

Digital leaders also innovate openly with others. They hold hackathons. They crowdsource. They co-create with customers and partners. They also contribute back to the community with projects such as Walmart Labs, Ericsson’s open-source hub and GE’s Industrial Dojo for the Cloud Foundry ecosystem.

Say RIP to RFPs

Digital leaders have pulled the plug on massive RFPs for complex, multiyear development projects. Instead, they favor faster, more flexible procurement processes that reward innovation and accelerate vendor selection. They conduct POC tests to evaluate alternative technologies. They use iterative prototyping to refine requirements and determine the best solution for the job. They keep their options open with shorter timelines and smaller deliverables.

Digital success calls for a more collaborative relationship with technology providers. It’s the whiteboard sessions, technical conversations and joint problem-solving that yield breakthrough results. That’s why progressive companies now approach the RFP like a “request for partnership.”

Integrate Data and Systems in Transformative Ways

Digital leaders use open platforms and APIs to integrate information, people and processes across their extended value chain. These connections lay the foundation for faster business flows and new digital products and services.

Connect Quickly with APIs

APIs (application programming interfaces) enable diverse applications to connect and share data. Digital leaders use API-led integration to combine services and expose information in ways that deliver unprecedented customer and business value. Within days and without lots of coding, they can roll out service innovations, revamp internal processes, enliven customer interactions, extend their digital reach and enable entirely new business models.

This year, 2017, has been dubbed the year of the API economy. ProgrammableWeb lists more than 17,700 APIs and hundreds of digital leaders are opening up their APIs so others can easily integrate and innovate with their technologies. API marketplaces from Mastercard, ADP, Ford and FedEx are just a few examples.

Achieve Digital Flow

Silos slow the flow of business. Disconnected processes, departmental barriers and gaps in information all impede speed and agility.

Digital leaders excel at silo-busting. They integrate disparate systems. They connect processes from end to end, across all customer touchpoints and organizational boundaries. They use open platforms to ensure that information—structured data and unstructured content—flows to the right person, at the right time, in the right context.

The seamless integration of information, people and processes allows digital leaders to be much more nimble and responsive. They can also leverage these connections to make huge improvements in customer experience—such as the bank that slashed loan origination steps by 70 percent or the insurer that processes claims 25 percent faster.

Bring Business and IT Closer Together

Digital leaders treat digital transformation as a partnership between business and IT, with a shared focus on meaningful outcomes and better experiences for customers and employees.

Engage and Empower Users

Digital leaders put people—customers, citizens, employees and partners—at center of their transformation efforts. They prioritize design thinking, a user-centric approach that shifts the focus from adding features to adding value. They take advantage of platform tooling to involve users in solution design and invest in dedicated UX teams to deliver better experiences faster. Capital One, for instance, regularly solicits customer input at its three innovation labs. Other proponents of design thinking include Citrix, Airbnb, BMW, DHL and Procter & Gamble.

Another winning strategy is to empower users with self-service tools that add business agility. Examples include self-service analytics for rapid decision-making and process services that make it easy for users to modify workflows as business needs change.

Take a More Strategic Role

Now that every company is a software company, IT is increasingly strategic to the enterprise. Successful CIOs have seized this opportunity and are making the most of it.

Forward-thinking IT leaders have recast IT in the role of business partner and change agent for digital transformation. They look for ways to drive growth, deepen customer engagement and shorten time to market. They help colleagues understand and realize the value of digital initiatives. They build bridges and buy-in by adopting a service mindset—what one CIO calls “ego-free IT.” The new measures of success aren’t IT-specific metrics; they’re meaningful business outcomes such as dollars saved, customers added and market share gained.

Conclusion

Every digital transformation is different. But the underlying challenge is the same. How can IT accelerate the pace of delivery and change simultaneously? By following the lead of digital trailblazers, any organization can gain the speed and agility needed to compete in a digital-first world—and win.

About the Author / Chris Wiborg

Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.

September 18, 2017
Today’s DNS: DevOps’ New Best Friend
Continuous development and deployment is a primary focus of DevOps teams. As part of this process, DevOps teams also require the automatic creation or removal of networks, and automated deployment to production. Automation is a closer guarantee that the process will be done right the first time because the fewer the number of manual steps involved, the less likelihood for human error. Intelligent DNS improves DevOps project life cycles by integrating DNS tasks into your software development and automation tools.

DNS Needs an Upgrade

The internet has come a long way since its humble beginnings, from the Advanced Research Projects Agency Network (ARPANET) of the 1960s to an entity that is mission-critical for the world’s commerce. This system is now tested and taxed in ways that were not even conceived of when it was originally designed. One of these early elements, DNS, is now a potential bottleneck for network performance in general and DevOps teams in particular.

One of the benefits of cloud computing is that it enables DevOps teams to automatically create and remove servers as needed for development and testing. Infrastructure as code (IaC) enables cloud computing to build infrastructure automatically using robust APIs that build servers and add applications as needed. Traditional DNS, with its mostly manual management, becomes a bottleneck for this automated rapid configuration of infrastructure. This is why organizations need an intelligent DNS solution. Intelligent DNS with a robust API can seamlessly interface with current DevOps software, removing the bottleneck that traditional DNS can become.

Extending Agile with DevOps

The underlying ideas of agile programming are extended with DevOps. Rather than the traditional way of producing and testing the code, then tossing it over the wall to the network operations team to deploy, DevOps merges the development, testing and operations responsibilities. In short, DevOps should have the ability to break the silos within your IT environment and among the development, QA and operations teams.

DevOps’ blend of cultural philosophies, practices and tools increases an organization’s ability to deliver applications and services at high velocity. DevOps allows organizations to evolve and improve products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

Rapid Change Propagation is Essential

In addition to rapidly delivering applications and services, a goal of DevOps continuous release is to remove bottlenecks to the development, testing, and deployment cycles. This is aimed at creating an environment where the work isn’t hampered with computer delays and frustrations.

When you’re automating the creation or deletion of 100 virtual servers with a single mouse click using IaC, waiting for 30 minutes to see if DNS changes appear at the edge servers delays your project. Your DNS needs to move as fast as your IaC software and service discovery processes. At this point, intelligent DNS with rapid change propagation becomes essential. When choosing DNS vendors to support your DevOps environment, make sure to include speed testing for the network’s propagation for changes.

Where IaC Comes In

The aim of DevOps professionals is to create and sustain server environments that closely resembles the way software developers build and maintain application source code. IaC is the way DevOps teams make that happen.

IaC is based on three primary constituents:
- Unit/Integration Testing – Lets you validate your infrastructure code within various phases of the DevOps pipeline and lets you feel confident about what you are pushing to production.
- Infrastructure Blueprints – Supports the reusable, consistent and rapid deployment part of IaC.
- Version Control – Facilitates the method track and rollback changes to your infrastructure as needed.
Infrastructure blueprints can be created using configuration as code (CaC). Using tools such as Terraform, Ansible and Chef allows DevOps teams to build these blueprints by enabling a declarative way of handling infrastructure configuration. Infrastructure blueprints should always go hand in hand with unit/integration testing. Having a robust, API-driven DNS network to couple the full automation of DNS changes alongside the infrastructure and configuration changes ensures a smoother process.

IaC is next-generation technology for DevOps environments. When combined with CaC products, it changes the way software is built and delivered. Continuous integration and continuous deployment are a large part of the DevOps world that all still depends on DNS technology to connect everything on the network.

The Role of Service Discovery

Service discovery is needed to enable your apps or servers to identify which services are available on the network and which IP addresses and ports are associated with them. Previous methods of tracking this information no longer work in the DevOps age.

Since modern infrastructure is so scalable and changes so quickly, keeping track of service information inside a periodically updated database doesn’t work anymore. Instead, you have to be able to discover services in real time and update your service information continually. Three common service discovery tools are: Consul, Apache Zookeeper and Etcd (with Registrator and confd).

A tight integration with your managed DNS provider as part of your overall strategy means that service discovery can work hand in hand with the DNS configuration so both systems remain in sync.

Moving Toward Intelligent DNS

DevOps needs the same types of robust features you would want for your external internet traffic: end user-facing DNS. You should align with a vendor that can provide the flexibility, agility and reliability you require to deliver your applications.

Look for features including:
- Zone Transfers allowed and easily facilitated
- An anycast DNS network
- A robust API to support automation, IaC, service discovery and other architecture and tool needs
- Native integration with common DevOps tools such as Terraform, Ansible and Chef
- An SLA that meets your needs for reliability and performance
These elements are necessary, but a more important item on your checklist needs to be redundancy in all layers of the stack, including DNS. Because no vendor is completely bulletproof, use at least two authoritative DNS providers to set up redundancy. Following these guidelines will improve your DevOps’ life cycle by using intelligent DNS.

About the Author / Kimberly Lacerte

Kimberly Lacerte has 14 years of experience in computer and technical writing. She is currently the Content Marketing Manager at NS1 in Bedford, N.H. Previously, she has written for Veritas, Symantec, Health Dialog and Dyn. Kimberly holds an English BA from UNH and an MBA from Southern NH University.
August 29, 2017