All successful cloud migration projects start with up-to-date knowledge of a company’s current infrastructure and application landscape. While it may seem obvious, many organisations don’t have a clear picture of what’s running in their environments. This picture helps the migration effort both before and after the migration. I’ll mention how in a bit, but first, what should we look for?

Audit

One obvious category is information about the workloads themselves. Almost all platforms come with reporting tools that tell you about the workloads running on them. That information, extracted from all platforms and kept in an easily manipulated format, such as a spreadsheet, forms the initial scope for migration.

Networking design will undoubtedly change beyond recognition as part of cloud migration, but it’s crucial to have an in-depth understanding of the existing topology, the rationale behind that design, type, and quantity of traffic that goes over the various links.

Knowing the complete breakdown of the costs of running the existing service is a must. Hardware and software costs for the platform and data centre costs are obvious ones, but the headcount required for operations is often forgotten. Make sure that they’re also considered.

What about who owns which service and who is the technical authority for it? These are often different people with different priorities. It’s not enough to just put any names there. It’s very important that the named individuals know about and agree to hold those roles for that service.

Pain points are excellent indicators of what are important issues to resolve. For example:

How long does it take for operations to deploy a machine?

Does the application scale under load? If so, what are the response times?

How long do the developers have to wait before they get their test platforms?

Are current processes automated or do they require manual intervention?

These measurements define your KPIs (key performance indicators) and will be used later to measure success. Those indicators must be well-defined, and their values should prove categorically if the state has improved or deteriorated. Once defined, values of those indicators should be carefully documented for the pre-migration state, with careful consideration that no correction is carried out before the measurements are taken.

Benefits Before Migration

Once the audit is done, the picture starts to become clearer. Let’s take the infrastructure spreadsheet for starters. Initially, it will be a crude list of workloads, but with a bit of thinking, the team can determine how many of them should be in-scope to move. They could be all production and development machines, but what about test machines?

It could also be that the hosting platform is creaking under the workload, increasing the urgency to migrate, to avoid capital investment into more hardware. This audit may identify workloads that are forgotten but can be removed to reclaim precious resources, thereby creating breathing space and buying more time to migrate.

Before the design phase, having all networking information in-hand is extremely important, as networking costs are calculated very differently in the public cloud. Not only are they highly-dependent on the design, but they can influence the final design.

It’s also a good opportunity to look at workloads to see if there are any unusual machines in terms of resource allocation or licenses that may not fit nicely when moved to a public cloud platform. Some rationalisation in that area can help reduce pain when going ahead with the design.

If not already done, this exercise also gives a good estimation of potential infrastructure costs on the various cloud platforms and can also feed into business case conversations.

Benefits After Migration

Going through the audit process makes it easier to carry the habit through into the new platform, especially if it proved to be useful. Data gathered can also be extended to contain additional data points that might have been useful to have initially but were only discovered as part of the migration.

In the short term, after-migration costs are seen to increase. That is because in the initial stages of migration, both source and destination environments are running in parallel. In such situations, having the audit done with exact cost breakdown helps to explain that behaviour.

A key milestone in the migration project is to show the business that you as a team have achieved the goals that were set out in the cloud migration business case. That’s where the effort spent in defining those KPIs and documenting the values comes in handy. New data returned into those KPIs post-migration becomes the determining factor for project success or failure.

Conclusion

Having the current, complete, and accurate data in-hand is the first practical step in starting the migration journey. That should contain data from all the sources that will be affected by the migration. Most importantly, it should contain the KPIs that will determine success or failure and their measurements before and after migration.

It’s important because while one can announce a migration to be a success, as W. Edwards Deming said:

This week’s Actuator comes to you live from Darmstadt, Germany - and from SQL Konferenz. If you're here, please stop me and say hello—I'd love to talk data and databases with you. And maybe some speck, too.

As always, here are some links from the Intertubz that I hope will hold your interest. Enjoy!

This sounds great, but what would be even greater is allowing for easy access to early voting. But if America really wants to increase voter turnout, we should offer a basket of chicken wings (or bacon) to everyone that votes.

The best quote I saw about this story was from New York State Senator Michael Gianaris who said “Like a petulant child, Amazon insists on getting its way or takes its ball and leaves.” Good for NYC to reconsider handing billions of dollars to a company that does not need the money.

If you’re just joining the series now, you can find the first two posts here and here.

Last time, I talked about the various decision points and considerations when using the public cloud. In this post, I’m going to look at how we build better on-premises data centres for hybrid IT. I’ll cover some of the technologies and vendors that I’ve used in this space over the last few years, what’s happening in this space, and some of the ways I help customers get the most from their on-premises infrastructure.

First of all, let’s start with some of my experience in this area. Over the years, I have spoken at conferences on this topic, I’ve recorded podcasts (you can find my most recent automation podcast here https://techstringy.wordpress.com/2018/11/27/automate-all-of-the-things-jason-benedicic-ep82/), and I’ve worked on automation projects across most of the U.K. In my last permanent role, I worked heavily on a project productising FlexPod solutions, including factory automation and off-the-shelf private cloud offerings.

Where Do You Begin?

Building better on-premises infrastructure doesn’t start where you would expect. It isn’t about features and nerd-knobs. These should be low on the priority list. Over the last few years, perhaps longer than that, since the mainstream adoption of smartphones and tablets, end users have had a much higher expectation of IT in the workplace. The simplicity of on-demand apps and services has set the bar high; turning up at work and having a Windows XP desktop and waiting three weeks for a server to be provisioned just doesn’t cut it.

I always start with the outcomes the business is trying to achieve. Are there specific goals that would improve time-to-market or employee efficiency? Once you understand those goals, start to look at the current processes (or lack thereof) and get an idea for what work is taking place that creates bottlenecks or where processes spread across multiple teams and delays are created with the transit of the tasks.

Once you’ve established these areas, you can start to map technologies to the desired outcome.

What Do I Use?

From a hardware perspective, I’m looking for solutions that support modularity and scalability. I want to be able to start at the size I need now and grow if I must. I don’t want to be burdened later with forklift replacement of systems because I’ve outgrown them.

Horizontal growth is important. Most, if not all, of the converged infrastructure and hyper-converged infrastructure platforms offer this now. These systems often allow some form of redistribution of capacity as well. Moving under-utilised resources out to other areas of the business can be beneficial, especially when dealing with a hybrid IT approach and potential cloud migrations.

I’m also looking for vendors that support or work with the public cloud, allowing me to burst into resources or move data where I need it when I need it there. Many vendors now have at least some form of “Data Fabric” approach and I think this is key. Giving me the tools to make the best use of resources, wherever they are, makes life easier and gives options.

When it comes to software, there are a lot of options for automation and orchestration. The choice will generally fall to what sort of services you want to provide and to what part of the business. If you’re providing an internal service within IT as a function, then you may not need self-service portals that would be better suited to end users. If you’re providing resources on-demand for developers, then you may want to provide API access for consumption.

Whatever tools you choose, make sure that they fit with the people and skills you already have. Building better data centres comes from understanding the processes and putting them into code. Having to learn too much all at once detracts from that effort.

When I started working on automating FlexPod deployments, the tool of choice was PowerShell. The vendors already had modules available to interact with the key components, and both myself and others working on the project had a background in using it. It may not be the choice for everyone, and it may seem basic, but the result was a working solution, and if need be, it could evolve in the future.

For private cloud deployments, I’ve worked heavily with the vRealize suite of products. This was a natural choice at the time due to the size of the VMware market and the types of customer environments. What worked well here was the extensible nature of the orchestrator behind the scenes, allowing integration into a whole range of areas like backup and disaster recovery, through to more modern offerings like Chef and Ansible. It was possible to create a single customer-facing portal with Day 2 workflows, providing automation across the entire infrastructure.

More recently, I’ve begun working with containers and orchestration platforms like Kubernetes. The technologies are different, but the goals are the same: getting the users the resources that they need as quickly as possible to accelerate business outcomes.

But Why?

You only have to look at the increasing popularity of Azure Stack or the announcement of AWS Outposts to see that the on-premises market is here to stay; what isn’t are the old ways of working. Budgets are shrinking, teams are expected to do more with less equipment and/or people, businesses are more competitive than ever, and if you aren’t being agile, a start-up company can easily come along and eat your dinner.

IT needs to be an enabler, not a cost centre. We in the industry all need to be doing our part to provide the best possible services to our customers, not necessarily external customers, but any consumers of the services that we provide.

If we choose the right building blocks and work on automation as well as defining great processes, then we can all provide a cloud-like consumption model. Along with this, choosing the right vendors to partner with will open a whole world of opportunity to build solutions for the future.

Next time I will be looking at how location and regulatory restrictions are driving hybrid IT. Thanks for reading!

This is part 3 in a series that began here and continued here, which found life-lessons for IT practitioners up on the big screen in the movie “Spider-Man: Into the Spider-Verse”. (I did something similar for the movies “Doctor Strange” and “Logan.”)

If you missed the first two issues, use those links to go back and check them out. Otherwise, read on, true believers!

Spoilers (duh)

As with any deep discussion of movie-based content, I’m obligated to point out that there will be many spoilers revealed in what follows. If you have not yet had a chance to enjoy this chapter of the Spider-Man mythology, it may be best to bookmark this for a later time.

Humility is its own reward.

It could be said that, if honesty about those around us is the source of empathy, then honesty about ourselves is the source of humility.

Along with empathy, humility is the other great value to which we can aspire. Not the false humility of someone fishing for more compliments, nor humility that originates from low self-esteem, but honestly understanding our own motivations, strengths, and weaknesses, and keeping them in perspective.

In IT, humility allows us to clearly see how our work stacks up against the challenges we face; how to best utilize the people, skills, perspectives, and resources at our disposal; whether our approach has a realistic chance of success or if we need to step back and consider a new path; and more. Humility moves ego out of the way and lets us see things for what they are.

Of course, Spider-Man (Peter, Miles, and the rest of the Spider-Folk) is innately humble. That’s part and parcel of the mythology. No, the place I found this lesson was how the movie was humble about itself.

From the recognition that certain aspects of the Spider-Man franchise were poorly conceived (Spidey-O’s cereal, “evil” Toby Maguire); or poorly executed (the 1977 TV series); or both (the Spider-Man popsicle), this movie is intent on letting the audience know that it knows the complete Spider-Man pedigree, warts and all. But the humility goes deeper than that.

After the third origin montage of the movie, you get the feeling the writers were never taking themselves that seriously. You sense that they are now making a commentary on just how many Spider-Man origin movies there have been (and how unnecessary some of them were). Miles’ comment “how many of us are there?” is a direct reference to the insane number of reboots the franchise has undergone. And the title of the comic Miles’ dorm-mate is reading (“What If... There Was More Than One Spider-Man?”) shows the movie is aware of its own preposterous nature.

The overall effect ends up endearing the characters, the plot, and the narrative to us even more, in the same way that “Spaceballs” and “Galaxy Quest” were to their respective franchises. The humility becomes a love letter to the story and the people who have invested so much into it.

Understand how to relax.

Played mostly for laughs, Miles’ initial inability to “let go” of things using his spider ability is a wonderful metaphor, especially for those of us in problem-solving roles, who often find ourselves asked to do so in stressful situations (like when the order entry system is down and the boss’s boss’s boss is hovering over your shoulder).

Whether it’s meditation, exercise, raging out to metal, travel, perfectly rolled sushi, looking at art, getting lost in a book, enjoying a fine Scotch (or wine, or chocolate, or doughnut), or gaming non-stop, you need to know for the sake of your ongoing mental health what it takes for you to unwind. While many of us find most of our work in IT fulfilling, there will always be dark and stressful times. In those moments, we need to be able to honestly assess first that we are stressed, why, and finally, how to remove some of that stress so that we can continue to be effective.

As the movie illustrates, not being able to let go can get in the way of our ability to succeed (hanging from the lights in Doc Oc’s office), and even hurt those around us (Gwen’s hair).

When you get quiet and listen to your inner voice, that’s when you are the most powerful.

Since “Into the Spider-Verse” is largely an origin story about Miles’ transformation into his dimension’s one-and-only Spider-Man, much of the action focuses on him learning about his powers and how to use them. The difference between this and many other superhero origin stories is that Miles is surrounded by the other Spider-Folk, who are much more experienced. This comes to a head near the end of the movie, when the others decide that Miles’ inexperience is too much of a liability and leave him behind. After an entire movie of Miles running, jumping, and awkwardly swinging from moment to moment, idea to idea, and crisis to crisis, this is where, for the first time, Miles finally stops and just is for a moment. He takes a few precious seconds to center himself, to understand where he is, and where he wants to be. In that moment, he is finally able to get in touch with all his abilities and control them.

Much like knowing how to relax and let go, being able to “check in” with ourselves in this way is incredibly powerful. Over the length of our IT careers, we will find ourselves surrounded, as Miles did, by people who are doing the same work as us but are vastly more experienced and confident about it. If we’re lucky, some of those people will be patient with us as we learn the ropes. But even so, being patient with ourselves—being able to stop for a moment in the middle of the cyclone of ideas, tickets, questions, incidents, doubts, system failures, and fears—will serve us well.

Pushing outside of our comfort zones is good, but if it doesn’t fit, we need to recognize it before we hurt ourselves.

“Try harder than you think you can!” “Push yourself just a little further!” “Do more than you planned!”

It seems like the message to try and exceed our limits is everywhere, and is mostly a positive one. We should want to keep improving ourselves, and having a cheerleader (even an inspirational coffee mug) can be an effective way to reinforce that desire.

But there can come a point when our attempt to push through the discomfort in pursuit of growth becomes unhealthy. When we are no longer “lean and mean,” but “emaciated and ornery;” when we’ve trimmed the fat, stripped the muscle, and are now cutting into bone.

In the movie, this lesson becomes clear when we see the other Spider-Folk experience the slow but deadly effects of being in a dimension not their own. Their cells are slowly dying, and if they don’t get back home, they have no hope of survival.

In our dimension—where we’re more likely to be accosted by users claiming “the internet is down” than by plasma-gauntlet wielding stalkers—it would be nice if being dangerously outside of our comfort zone was as clear. Sometimes it is. Many of us have experienced the effects of long-term exhaustion, drained of motivation and unable to focus. The movie is teaching us that we need to first understand what is happening to us, and then work to find our way “home.”

As I described earlier, maybe that means centering ourselves and determining what we really need; or maybe doing something relaxing until we’ve recharged. But to not do so, to keep powering through in the vain hope that we’ll somehow find equilibrium, is as deadly to us (our career, if not our health) as being in dimension 1610 (Miles Morales’ home) when we belong in 616.

It’s never too late to try again

I’ve already commented on the state of dimension 616’s Peter—his emotional state at the start of the movie, the condition of his relationships, etc. And I’ve also commented on how, by the end of the movie, he’s beginning to take steps to repair his life. As moviegoers, we are invited to compare that choice to Wilson Fisk’s. His way of fixing his mistakes was to steal something that wasn’t his. We’re left to wonder, even if he had succeeded in spiriting a copy of Vanessa and Richard from another dimension, how would they survive? What would they think of him? So much about his choice leads only to more problems, more mistakes. It’s not that Peter’s path is easy. But if reconciling with Mary Jane is difficult (even if it’s ultimately unsuccessful), it’s still the only way to move ahead.

I am reminded of two business-critical failures, occurring a week apart, that I observed at a particular company. In both cases, a human error by a technician caused the failure.

In one case, the tech came forward immediately, owned up to what happened, and offered to help resolve it. Even after it was evident that the failure extended beyond their skillset, this person stuck around to watch, so they would learn and know more next time. The incident was resolved, and nothing more was ever said.

In the other case, the technician did everything they could to cover up the event, and their role in it. The truth came out fairly quickly (never forget that there are logs for everything) and the employee was literally walked out the door.

The lesson for IT pros should be clear. Even after a critical failure, we have opportunities to improve, fix, and ensure that next time the outcome is better. No technology failure spells “the end”—only our own attitude toward the failure can do that.

Final Lesson

In watching the Spider-Folk work together as a team, with all the similarities and differences in their abilities, attitudes, and personalities, I was reminded of an anonymous quote:

“In that which we share, let us see the common prayer of humanity.

In that which we differ, let us wonder at the freedom of humankind.”

If there is any lesson we can walk away with from this movie, it’s this: there is more about us that is the same than there is different; and both the similarities and the differences are the source of our strength as individuals and teams working in IT.

The Modernizing Government Technology (MGT) Act was passed in late 2017 to provide government agencies with IT-focused financial resources and technical expertise to replace legacy infrastructure. The goal of the MGT Act is to “allow agencies to invest in modern technology solutions to improve service delivery to the public, secure sensitive systems and data, and save taxpayer dollars.”

With extra IT funds, where will agencies spend that money?

It seems logical that agencies should use MGT funds to begin their cloud migration if they haven’t done so already, or to speed up the process of moving systems and applications to the cloud.

Yet, as a federal IT pro, how do you know which systems to migrate and which should stay on-premises?

Best Choice Apps for Cloud Migration

There are four primary things to consider:

Size

Complexity

Criticality to the mission

Variable usage

Size

Look at the amount of data your application is accumulating and the amount of storage it’s taking up. Lots of data and storage space can equal lots of money on databases and storage systems.

Agencies can save money in two ways when moving that data into the cloud. First, think of the reduced maintenance costs. Second, with a cloud environment you’re only paying for what you use, which means you can add storage capacity on the fly if you need to or, just as important, remove storage you no longer need.

Complexity

Consider keeping your most complex applications on-premises until you’ve already undergone some application migration and understand the ins and outs of the process.

When considering complexity, think not only about the application itself, but think about its dependencies, connections, and associations. The more that application relies on or connects to other systems, the more complex it will be to migrate.

Criticality to the Mission

Save the most mission-critical applications for last or keep them on-premises. Think about development or staging environments and applications, disaster recovery systems, and many human-resources applications. This way, if there is a glitch in your migration, the agency will continue operating without interruption.

Another point worth making: home-grown applications may be far more complex to migrate and may be best off staying on-premises.

Variable Usage

Perhaps the area where federal IT pros can get the most bang for their buck in migrating to the cloud is in “bursty” applications. Think about applications that get heavy use during very specific time periods, such as during the tax season.

The challenge with keeping these types of applications on-premises is needing to have resources at the ready for these heavy-use periods—resources that otherwise can go unused. This is precisely what makes them ideal for cloud migration.

Consider, too, the applications that require batch processing for the very same reasons.

Conclusion

The MGT Act is good news for federal IT pros, giving them the opportunity to move their infrastructure forward. For many agencies, cloud and hybrid IT may be the ideal place to start.

Cost plays a factor in most IT decisions. Whether the costs are hardware- or software-related, understanding how the tool’s cost will affect the bottom line is important. Typically, it’s the engineer’s or administrator’s task to research tools and/or hardware to fit the organization's needs both fiscally and technologically. Multiple options are available to organizations from open-source tools, proprietary tools, and off-the-shelf tools for purchase. Many organizations prefer to either build their own tools or purchase off-the-shelf solutions that have been tried and tested. However, the option of open-source software has become increasingly popular and adopted by many organizations both in the public and private sector. Open-source software is built, maintained, and updated by a community of individuals on the internet and it can change on the fly. This poses the question: is open-source software suitable for the enterprise? There are both pros and cons that can make that decision easier.

The Pros of Open-source Software

Open-source software is cost-effective.Most open-source software is free to use. In cases where third-party products are involved, such as plug-ins, there may be a small cost incurred. However, open-source software is meant for anyone to download and do with as they please, to some extent based on licensing. With budgets being tight for many, open-source could be the solution to help stretch your IT dollars.

Constant improvements are a hallmark of open-source software.The idea of open-source software is that it can and will be improved as users see flaws and room for improvements. Open-source software is just that: open, and anyone can update it or improve its usage. A user that finds a bug can fix it and post the updated iteration of the software. Most large-scale enterprise software solutions require major releases to fix bugs and are bound by major release schedules to get the latest and greatest out for their customers.

The Cons of Open-source Software

Open-source software might not stick around. There’s a possibility that the open-source software your organization has hedged their bets on simply goes away. When the community behind updating the software and writing changes to the source code closes up shop, you’re the one now tasked with maintaining it and writing any changes pertinent to your organization. The possibility of this happening makes open-source a vulnerable choice for your organization.

Support isn’t always reliable. When there is an issue with your software or tool, it’s nice to be able to turn to support for help resolving your issue. With open-source software, this isn’t always guaranteed, and if there is support, there aren’t usually the kind of SLAs in place that you would expect with a proprietary enterprise-class software suite.

Security becomes a major issue. Anyone can be hacked. However, the risk is far less when it comes to proprietary software. Due to the nature of open-source software allowing anyone to update the code, the risk of downloading malicious code is much higher. One source referred to using open-source software as “eating from a dirty fork.”When you reach in the drawer for a clean fork, you could be pulling out a dirty utensil. That analogy is right on the money.

The Verdict

Swim at your own risk. Much like the sign you see at a swimming pool when there is no lifeguard present, you have to swim at your own risk. If you are planning on downloading and installing an open-source software package, do your best to scan it and be prepared to accept the risk of using it. There are pros and cons, and it’s important to weigh them with your goals in mind to decide whether or not to use open-source.

Few messages strike fear in the hearts of IT operations staff like the dreaded scan results from your security team. These messages often appear in your inbox early on Monday morning, which means it’s sitting there waiting for you. You’re not even into your second cup of coffee when you open the message:

Good morning,

Your servers have 14,000 vulnerabilities that must be resolved in 14 days. See the attached spreadsheet for a wall of text that’s entirely useless and requires a few hours to manipulate into actionable information.

Love,

Security

Sure, I’m exaggerating a bit. But only a bit.

The relationship between operations and security is fraught with tension and calamity. Often, communications from the security team indicate a lack of understanding of patching and change management processes. And equally often, communications from the operations team indicates a lack of exigency regarding addressing the vulnerabilities. But ironically, you’ll hear the same observations from both teams: “We’re just trying to do our jobs.”

For operations, the job is managing server lifecycles, handling tickets, responding to alerts, ensuring backups run, and generally juggling flaming chainsaws. For security, the job is scanning networked hosts for known vulnerabilities and missing patches, compiling reports for the executives, and disseminating scan results to the cognizant technical teams for resolution.

The problem inherent in these teams’ goals is this: there’s no clear accountability for the security of the network and its systems. Without this clarity, you’ll end up with an IT shop that is more focused on placating the other teams than it is on security.

This is where SecOps can save the day.

What Is SecOps, Anyway?

At this point, you might be thinking, “SecOps… sounds like DevOps. And that is a meaningless buzzword that belongs in the garbage heap of forgotten IT trends.” I hear you. These terms are certainly overused, and that’s a shame. Both DevOps and SecOps can solve organizational problems that are the result of a generation of siloed org charts and team assignments. And just like DevOps brings together your application and infrastructure teams, SecOps brings together security and infrastructure.

In both cases, “bringing teams together” means that the existing battle lines get erased. For example, you maybe have a security team that uses a patch scanning tool to identify systems with missing patches. That tool likely has a built-in database that can track vulnerabilities for hosts over time. It might even include a reporting function that can extract recent scan results for a subset of hosts and place that information in a PDF or spreadsheet. This are all standard, reasonable expectations from a security team’s internal tools.

On the other side of the aisle is your operations team, with their own patch management solution that has been configured to act primarily as a patch and software deployment tool. The tool can determine missing patches for managed system and act as a central repository for vendor patches. It likely has its own built-in database for keeping track of patch deployments. And it might include a reporting function. Again, these are all basic tools and capabilities of the ops staff.

What’s the problem with this approach? You’ve got valuable data sequestered from staff who could put this information to good use. And the organization as a whole can’t turn that data into knowledge. And most importantly, the focus of these two teams’ interactions will be on finding fault in each other’s data as a means to discredit the team as a whole. I’ve seen this happen. You have, too. It’s not good.

How Can SecOps Help?

A SecOps approach would open up these two datasets to both teams. Security gets a view into your ops team’s patching process, and operations gets firsthand access to scan results for the systems they maintain. And something remarkable happens: instead of the conflict that is manufactured when two teams are each working with non-shared information, you get transparency. The conflict starts to ease. The focus shifts from appeasement to collaboration. And the distrust between the teams starts to fade.

OK, that might be expecting a little much from a simple change. Because these battle lines are ingrained in the minds of IT staff, you’ll want to be patient with your new SecOps practitioners.

The next step to bring about SecOps culture change is to align the goals of each team with the organization’s goals and vision. Before SecOps, your security team’s effectiveness may have been measured by the raw number of vulnerabilities it identifies each month, or quarter, or year. And your operations team may be measured by how many tickets it closed each month, or quarter, or year. But these measurements fail to put the focus where it belongs: on the shared responsibility to create and maintain a secure IT environment. These measures are also trailing indicators, and generally suggest a fundamental problem with patching or scanning or both.

Like all trends in IT, SecOps is no panacea for all of IT’s woes. And it requires buy-in from your technical staff who are likely suspicious of yet another “great idea” from the execs in the Ivory Tower. But with the right coaching, and the focus on SecOps as an iterative journey and not a point-in-time change, your organization will certainly benefit from bringing these teams together.

Had a great time in Austin last week for Tech Field Day 18. Now I am getting ready for my next trip, to Darmstadt, Germany, and SQL Konferenz. If you are reading this and near Darmstadt the week of the 20th, stop by and say hello. I'll be there talking about data, security, and privacy.

As always, here are some links from the Intertubz that I hope will hold your interest. Enjoy!

Well now, this brings up all kinds of questions. First off…how many arrests are they looking to make? I mean, if no one has broken a law, then they should expect zero arrests. It seems they are looking to increase their incarceration rates, considering they are fining people for hiding their faces.

Here’s an interesting article that hits close to home. Having supported federal clients at SolarWinds for over four years, I have seen firsthand the increase in complexity our customers need to manage.

As government networks become more complex, maintaining the highest levels of network performance is getting harder. The growth of hybrid IT makes things even more challenging.

How do federal IT pros maintain a consistent high level of performance under these conditions?

The State of IT Today

The right strategy starts with a good network management tool. Traffic monitoring across all networks, including hybrid IT networks, can help ensure you see where users are going, the IP addresses they’re coming from, and if they’re trying to access unauthorized information or files.

You should also have the ability to analyze that traffic. Be sure you can see network performance across hybrid IT landscapes, and cloud XaaS (Anything-as-a-Service) solutions. For the best results, look for solutions that provide auto-generating, contextually aware maps of network traffic. This can provide far clearer visualization of network performance throughout the entire environment.

Inventory as It Relates to Capacity

Maintaining an inventory of all hardware, software, applications, and equipment connected to your network is a best practice. This not only gives you a snapshot of your IT asset inventory, but also allows you to quickly detect unauthorized users.

Inventory becomes a critical component of scalability, which will contribute to better network performance. The better a federal IT pro can understand a given inventory, particularly based on historic data, the greater the ability to forecast future network-infrastructure needs.

An Application Perspective

Understanding the applications powering the network is the next cornerstone of effectively optimizing network performance. This requires developing a holistic view of all applications, which in turn will result in a better understanding of how the performance of applications may affect the entire application stack.

Federal IT pros need a network tool that can quickly identify and rectify performance issues and bottlenecks without having to hunt through layers of applications to find the root of the problem.

The Right Strategy: Resiliency and Reliability

Effective network management also involves implementing the right strategy that is strongly focused on the information you collect. How you interpret that data, and ensuring the validity of the data, can be the difference between success or failure.

Resiliency and reliability are also critical performance metrics. Resiliency is the ability to provide and maintain an acceptable level of service in the face of faults and challenges to normal operation. Reliability is a system’s ability to recover from infrastructure or service disruptions, automatically scale resources to meet demand, and mitigate service disruptions, including misconfigurations.

Resiliency and reliability underscore the value that federal IT pros can bring to fruition for their agencies. They also represent measures of how well a distributed application was integrated and delivered, and also depict overall performance.

So, remember, to optimize performance, look to leverage tools that deliver full-stack observability into the logs, metrics, and tracing data that underpin reliability and resiliency metrics.

There’s a question I’m sure is keeping some IT managers and CTOs up at night. How do you know when it’s right to move a workload to the cloud? And when you finally make the decision to migrate, how do you choose the best location for your application?

As mentioned in my previous post, cloud is a buzzword that carries with it a lot of white noise that IT managers and departments need to cut through to see whether it’s a worthwhile venture for their organisation. New three-letter initialisms and hyperbolic marketing campaigns are hitting inboxes daily. Vendors are using studies and figures from advisory firms like Gartner, IDC, and Forrester to back up their elaborate stance on cloud. Yet there is no denying that more companies and applications than ever are transitioning to the cloud.

Before I go further, I just want to level-set a few things. Firstly, “cloud” is a service-oriented architecture. Depending on the amount of abstraction you want within the application stack, we have Infrastructure as a Service (Iaas), Platform as a Service (PaaS), and Software as a Service (SaaS). As we move towards SaaS from IaaS, we sacrifice control to gain flexibility and scale.

More often than not, “cloud” is used in reference to the public cloud, a collection of services available to the public to consume, at will, via the internet. Private cloud, on the other hand, refers to everything from the data centre, the racks, the servers, and networking, through the various operating systems, to applications. The intent is to provide a service or services to a single company or organisation. It can be argued whether this private cloud infrastructure requires the ability to be controlled via a programmable interface to facilitate self-service and automation.

To decide where a piece of software or software stack runs, we need to look at the different aspects that can come into play between public and private cloud. One of the first things to do is consider the total cost of ownership for each deployment. While the public cloud gives you the ability to quickly deploy and rapidly scale with known operational pricing, you still need to monitor and assess whether you’re gaining the right amount of agility to performance. With on-premises hardware and software, you can have greater control over costs because you can calculate your requirements then add in the environmental, management, support, backup, disaster recovery, and decommission costs before spending a penny. The downside to this is that you have to “guesstimate”’ how much your application’s usage will increase over its lifespan. What will happen if your company takes on 1,000 new employees or acquires another business unit that needs to be integrated? If you go too big, you have overspent and underutilised, which nobody wants to do.

Yet a benefit from running it on-premises or in a private cloud is that you have far greater control over the versioning within your stack as well as maintenance windows that work with your company’s fiscal calendar. In the public cloud or off-premises, you probably have very little control over these factors and may have to add layers of complexity to deal with things like maintenance windows.

Which leads us into decisions that will need to be made regarding disaster recovery and the ability to avoid disruption. With a private cloud, you’ll need to purchase two sets of infrastructures (identical if you want complete disaster recovery), which then poses the question—do you sweat that asset and spread your workload over the two sites, thereby increasing the management overhead for your organisation? This leads to a greater initial capital expenditure (although financing options are available) and then a longer delivery, setup, burn in, benchmark, and tuning period before you can go live. On the other side, we can code site fault tolerance into the majority of public cloud services at deployment time, with several providing this as a default setting with services like databases and others where it can be “retrofitted” as required.

Reading this, you probably feel that the public cloud is ahead in this race to acquire your next application deployment, but there are drawbacks. A large one that needs mentioning is, “Can the data live there?” Regulatory bodies like HIPAA, FERPA, SOX, and GDPR have rules to help protect customers, consumers, and patients alike, so decisions on which cloud and usage of technologies like VPNs, encryption, and more are detailed in their frameworks. There are also concerns that need to be addressed around how you connect to the application and manage security for this environment so you don’t end up on the front page of the Wall Street Journal or Financial Times.

It is very rare to find an organisation that is solely in the cloud. There are a greater number of companies who still operate everything in-house, but we are now seeing a trend towards the hybrid cloud model. Having the ability to run different applications on either the public or private cloud and the ability to change this during the lifespan of an application are becoming requirements for organisations trying to go through digital transformation.

While there are many cloud options available, it’s important not to get hung up on these, as an application may move during its lifecycle, just like a server or VM. It’s about what’s right for the business at that time and having the ability to react quickly to changes in your marketplace. That’s what will set you apart from the competition.

I have only touched on some of the points that I see as the ones of greater concern when discussing the various cloud options, but spending time investigating and understanding this area of computing and application delivery will put both you and your company in good stead.

A colleague recently mentioned to me that if you are not speaking to your customers about the benefits of cloud, you can be sure your rival is, so let’s make sure we frame the conversation correctly.

Great! You’ve made the decision to migrate to the cloud. What should be the first step towards that goal? The answer is: defining a cloud migration team that understands the vision, has skilled members to carry out required tasks, and is available to contribute as and when required.

The best compliment for an IT team is invisibility. It’s a sign of a well-oiled machine that provides everything that a business needs, anticipates problems, and rectifies them before they occur.

A cloud migration team is no different. It typically consists of members from various business units from within the company (although external skilled consultants can also be brought in) who are aligned to very specific and clearly-defined roles. If done correctly, even the most complex landscapes can be migrated with ease and transparently.

Think of the whole process as a drama: there’s a plot and colourful characters that play specific roles. There are ups and downs during the whole process. Occasionally, people get emotional and tantrums are thrown. The main thing is that by executing their role well, each team member works towards a happy ending, and by playing their part faithfully, that’s exactly what they get.

Essential Roles

The main character of this drama is the cloud architect. Appointing someone to this role early is essential. Leading the mission, this person is proactive, defines the scope and strategy, and identifies the wider team that will contribute towards a successful migration.

A great source of contributors is the group of stakeholders from the business, platform, security, and operation functions, who by now are already sold on the idea. That would indeed be the case if management has gone through evaluating the business need to go to the cloud and was part of the approval process. Not only can they provide resources to the project, but they also have the unique view from their own functional groups’ perspective that ensures all important bases are covered.

Commonly seen as the villain, the project manager is an extremely important role that keeps the cloud architect and other players on the straight and narrow. This role is not just about making a schedule and keeping everyone on time, but also to help prevent scope creep and foresee resourcing issues.

It’s easy to forget the “understudy,” but we are all humans and can fall ill unexpectedly—sometimes for long periods. People can also switch jobs. That can have a major impact on progress, especially if that person held an important role. Once the process starts, it’s important to keep the momentum going. That is made possible by having multiple people shadowing key roles where possible.

Skills

Nobody wants a bad actor in a drama. It can annoy the audience and derail the entire performance. Team members not suitably skilled for the role they’re assigned are likely to underperform and drag the whole team to a standstill.

That said, everyone wants to be a part of something special, and often, they are prepared to put the extra effort in to learn new skills. Career development and a sense of achievement by being part of a success story is a great motivator too.

The key is to identify the gaps early and send team members to appropriate training as soon as possible. The sooner this step is taken, the less pressured they feel when the project starts, and they can provide valuable input to important decisions early in the process.

Availability

Imagine what would happen if a character drops out from a performance every now and then. Worse, if more than one does it. Would that play be a success?

The same is true for a cloud migration project. While it can be a huge drain on a company’s resources, the commitment to provide the personnel necessary to carry out assigned tasks all the way to the end, is critical before embarking on that journey. Not doing so creates huge dependency issues that are hard to resolve and forces the entire schedule to go out of shape.

The day job doesn’t stop with a project like this, but a portion of time should be committed and prioritised. It’s almost impossible to commit resources full-time to a project, but as long as availability issues are communicated clearly and well in advance, the team can work around it.

Conclusion

The success of a migration project is highly dependent on the people assigned to the project. It is something that is interesting but also challenging at the same time. Delivery of a high-quality migration with minimal or no disruption requires a skilled team, clear roles and responsibilities, and the time commitment to think and plan properly.

Most importantly, we all know the magic that happens when all the characters are having fun. That production always becomes a knockout success.

When it comes to getting something done in IT, the question of "How?" can be overwhelming. There are many different solutions on the market to achieve our data center monitoring and management goals. The best way to achieve success is for project managers and engineers to work together to determine what tools best fit the needs of the project.

With most projects, budgets are a major factor in deciding what to use. This can make initial decisions relatively easy or increasingly difficult. In the market, you’ll find a spectrum from custom implementations of enterprise management software to smaller, more nimble solutions. There are pros and cons to each type of solution (look for a future post!), and depending on the project, some cons can be deal-breakers. Here are a couple of points to think about when deciding on a tool/solution to get your project across the finish line.

Budget, Anyone?

Budgets run the IT world. Large companies with healthy revenues have large budgets to match. Smaller organizations have budgets more in line with the IT services that they need to operate. Each of these types of companies need to have a solution that fits their needs without causing problems with their budgets. There are enterprise management systems to fit a variety of budgets for sure. Some are big, sprawling systems with complicated licensing and costs to match. Still others consist of community-managed tools that have less costs associated with them, but also have less support. And, of course, there are tools that fit in the middle of those two extremes.

Don’t think that having limitless budget means that you should just buy the most expensive tool out there. You need to find a solution that first and foremost fits your needs. Likewise, don’t feel like a small budget means that you can only go after free solutions or tools with limited support. Investigating all the options and knowing what you need are the keys to finding good software at reasonable costs.

Do I Have the Right People?

Having the right people on your IT staff also helps when choosing what type of management tool to use. Typically, IT pros love researching tools on their own and spend hours in community threads talking about tools. If you have a seasoned and dedicated staff, go with a more nimble tool. It usually costs less, and your staff will ensure it gets used properly.

Conversely, if your IT staff is lacking, or is filled with junior level admins, a nimble tool might not be the best solution. An enterprise solution often comes with more support and a technical account manager assigned directly to your account. Enterprise solutions often offer professional services to install the tool and configure it to meet the demands of your infrastructure. Some enterprise management software vendors offer on-site training to get your staff up to speed on the tool’s use.

Don’t forget that sometimes the best person for the job may not even be a person at all! Enterprise management systems often provide the ability to have tools that can automate a large number of tasks, such as data collection or performance optimization. If your staff finds itself overworked or lacking in certain areas, you may be able rely on your EMS platform to help you streamline the things you need to accomplish and help you fill in the gaps where necessary. Not everyone has the need for a huge IT team, but using your platforms as a force multiplier can give you an advantage.

There are many other points to discuss when deciding on an enterprise monitoring or management system versus a nimble tool. However, the points discussed above should be the most pertinent to your discussions. Do not make any decisions on a solution without taking the time to make some proper assessments first. Trust your staff to be honest about their capabilities, ensure your budgetary constraints are met, and choose a tool that will be the best fit for the project. In the end, what matters most is delivering a solution that meets your customer and/or company’s needs.

Spent the weekend making feijoada to have for the Big Game this past Sunday. If you found the game, commercials, and halftime show to be boring, I wanted you to know I had 7 different parts of a pig in a stew over rice. In a way, we are all winners.

As always, here are some links from the Intertubz that I hope will hold your interest. Enjoy!

In this post, I’m going to be focusing on public cloud. I’ll cover my day-to-day experiences in using the major hyperscalers, costs, how I think about managing them, and my reasons for adopting hybrid IT as an operational model.

By now, almost everyone reading this should have had some experience with using a public cloud service. Personally, I’m using public cloud services daily. Being an independent consultant, I run my own company and I want to be able to focus on my customers, not on running my own IT.

When setting up my business, it made perfect sense for me to utilise public offerings such as Office 365 to get my communication and business tools up and running. When I want to work on new services or train myself, I augment my home lab with resources within the public clouds. For these use cases, this makes perfect sense: SaaS products are cheap, reliable, and easy to set up. Short-lived virtual machines or services for development/testing/training are also cost effective when used the right way.

This works for me, but I’m a team of one. Does this experience translate well into other cases? That’s an interesting question because it isn’t one-size-fits-all. I’ve worked with a wide range of customers over the years, and there are many different starting points for public cloud. The most important part of any cloud journey is understanding what tools to use in what locations. I’ve seen lift-and-shift style migrations to the cloud, use of cloud resources for discrete workloads like test/development, consumption of native services only, and every combination in between. Each of these have pros and cons, and there are areas of consideration that are sometimes overlooked in making these decisions.

I want to break down my experiences into the three areas where I’ve seen cost concerns arise, and how planning a hybrid IT approach can help mitigate these.

Virtual Machines

All public clouds offer many forms of virtual machines, ranging in cost, size, and capabilities. The provisioning model of the cloud make these easy to consume and adopt, but this is a double-edged sword. There are several brilliant use cases for these machines. It could be that you have a short-term need for additional compute power to supplement your existing estate. It might be that you need to perform some testing and need the extra resources available to you. Other options include being able to utilise hardware that you wouldn’t traditionally own, such as GPU-enabled platforms.

When planned out correctly, these use cases make financial sense. It is a short-term need that can be fulfilled quickly and allows business agility. The cost vs. benefit is clear. On the flip side, leaving these services running long-term can start to spiral out of control. From my own test environment, I know that a running VM that you forget about can run up bills very quickly, and while my own environment and use cases are relatively small even for me, bills into the hundreds of pounds (or dollars) per month for a couple of machines that I had forgotten to shut down/destroy are common. Now multiply that to enterprise scale, and the bill can become very difficult to justify, let alone manage. Early adopters that took a lift-and-shift approach to cloud without a clear plan to refactor applications are now hitting these concerns. Initial savings of moving expenditure from Cap-Ex to Op-Ex masked the long-term impact to the business.

Storage

The cloud offers easy access to many different types of storage. The prices can vary depending on the requirements of that storage. Primary tier storage is generally the most expensive to consume, while archive tiers are the cheapest. Features of storage in the cloud are improving all the time and catching up to what we have come to expect from the enterprise storage systems we have used on-premises over the years, but often at additional cost.

Consuming primary tier storage for long-term usage quickly adds up. This goes hand in hand with the examples of monitoring VM usage above. We can’t always plan for growth within our businesses, however, what starts off as small usage can quickly grow to multiple TB/PB. Managing this growth long-term is important for keeping costs low; ensuring that only the required data is kept on the most expensive tiers is key. We’ve seen many public examples where this kind of growth has required a rethink. The most recent example that comes to mind is that of Dropbox. That might be an exception to the rule, however, it highlights the need to be able to support data migrations either between cloud services or back to on-premises systems.

Networking

Getting data to the cloud is now a relatively easy task and, in most instances, incurs little to no cost. However, moving data within or between clouds, and in cases of repatriation, back to your own systems, does incur cost. In my experience, these are often overlooked. Sprawl within the cloud, adopting new features in different regions, or running a multi-region implementation can increase both traffic between services and associated costs.

Starting with a good design and maintaining locality between services helps minimise this. Ensuring the data you need is as close to the application as possible and minimal traffic is widely distributed needs to be considered from the very start of a cloud journey.

Why a Hybrid IT Mindset?

With those examples in mind, why should we adopt a hybrid IT mindset? Having all the tools available to you within your toolbox allows for solutions to be designed that maximise the efficiencies and productivity of your business whilst avoiding growing costs. Keeping long-running services that are low on the refactor/replace priorities in on-premises infrastructure is often the most cost-effective method. Allowing the data generated by these services to take advantage of cloud-native technologies and systems that would be too costly to develop internally (such as artificial intelligence or machine learning) gives your business the best of both worlds. If you have short-term requirements for additional capacity or short-lived workloads like dev/test, giving your teams access to resources in the cloud can speed up productivity and even out spikes in demand throughout the year. The key is in assessing the lifetime of the workload and what the overall costs of the services consumed are.

Next time I’ll look at how we build better on-premises data centres to adopt cloud-like practices and consumption. Thank you for reading and I welcome any questions in the comments section.

In our last exciting installment I began delving into the IT-centric lessons we can glean from the latest addition to the Spider-Man franchise. (Just like I did in the past with the movies “Doctor Strange” and “Logan.”)

But like a good comic book series, one installment is never enough. Keep reading, true believers, to see what other jaw dropping discoveries await your eyes!

Spoilers (duh)

As with any deep discussion of movie-based content, I’m obligated to point out that there will be many spoilers revealed in what follows. If you have not yet had a chance to enjoy this chapter of the Spider-Man mythology, it may be best to bookmark this for a later time.

Even inelegant solutions can be powerful

At a few key moments of the action, help comes from an unanticipated direction—the more “cartoonish” abilities of Spider-Ham. Whether it’s a giant mallet he produces from I-don’t-want-to-know-where, or an anvil falling directly on the head of a villain, these great saves are played for laughs, but still have a lesson for us in IT.

“Have you turned it off and on again?” is an inelegant solution. But it works. So does restarting IIS to get the website back up. As do a million other “kludges” that IT professionals employ every day, sometimes feelings guilty about it.

My advice (and I believe Peter Porker would back me up on this): don’t overthink it. If a solution works, it works. That doesn’t mean you shouldn’t also make time to resolve the underlying problem. But always be open to use every tool in your toolbox, even an oversized wooden mallet.

Simple tech used with determination—even by less skilled folks—can be very effective.

Closely related to the previous lesson is that often your commitment to solving a problem is more important than the techniques or tools you use to solve it.

In the movie, this is best exemplified by Aunt May. Horrified at the destruction being done to her home, she takes matters (and a Louisville Slugger) into her own hands, and makes Tombstone understand that wearing muddy shoes inside her house will simply not be tolerated.

The moral for us is twofold. First, that our success as IT practitioners is less about the sophistication of tools, and more about our persistence in solving the problem.

On the flip side of this, when we see one of our colleagues, even someone we consider less “powerful” than we are (although anyone who judges Aunt May like that is in for a rude and likely painful surprise), we need to focus less on their technique or tools and more on their goals, putting us into the healthier and more productive role of supporting, rather than judging.

Trying to re-create, or worse, “fix” the past is a fool’s errand.

The best villains are the ones who don’t see themselves as such, but instead have deeply-seated motivations driving them to extreme lengths. In a different context, they might even be seen as a hero because of their determination to see a course of action through to the end. Such is the character of Wilson Fisk (aka Kingpin). We learn that in a single moment, Fisk lost the love and trust of his wife Vanessa. This triggered a rapid cascade of events, leading to the death of both Vanessa and their son Richard. Fisk cannot reconcile the pain of that loss, and therefore set himself on the path that leads to the catalyzing event of the movie—opening a rift between dimensions, finding an instance where Vanessa and Richard did not die, and pulling those living versions to him and make his life whole again.

Working in IT, there are pivotal moments where we realize we’ve made an error—sometimes the microsecond after hitting the ENTER key (c.f. the ohnosecond). These are moments we might wish to erase or undo. However, even if the technology existed, very few of us would do so if it meant hurting someone.

The lesson we can take from the movie is how damaging it can be to dwell on those past mistakes, replaying them over and over and saying, “if only.” I’m not saying that regret will turn you into a criminal mastermind. But I am saying that living in a regretful past will lead to nothing good.

Being multi-lingual is normal. Don’t fight it. Don’t make a big deal of it.

Miles Morales is celebrated for being one of the most compelling and relatable characters in comics, due in no small part because of his cultural heritage. He moves effortlessly between cultures, and one of the ways the movie shows this is when he flows from English to Spanish without hesitation (and without subtitles, which is part of my point below). Whether it’s the kids in his neighborhood, the teachers at his new school, or the villains crowding into Aunt May’s home in Queens, Miles is un-self-consciously fluent in the languages around him.

While I would love to make this lesson all about how I think all IT professionals should learn another language because it will help in ways they cannot possibly imagine, that’s not exactly my point. But if you want to change your life, learn to speak more than one language. Really.

My point is more about the way Miles’ multilingual nature is portrayed: it’s nothing special. Miles never acts as the interpreter to those around him. He never shouts, “Scorpion just said he’s going to knock you into next week!” He’s not there as a proxy for a non-comprehending audience. He’s there as a proxy for everyone else.

The lack of subtitles in the movie drives this home. Directors Bob Persichetti and Peter Ramsey made this choice purposefully, as if to say “This is a trivial aspect of this world. If it’s jarring to you, that’s you, not the story. Get used to it. This is how the world works.”

The lesson is that being multilingual is an IT thing too. Maybe not spoken languages, but modalities of computing. Cloud, hybrid IT, containers, software-defined networking, platforms-as-a-service—these are all part of the fabric of our work now. Even if we’ve put off learning to code the same way we put off learning French, the time is now for us to take another look, start to familiarize ourselves, and begin to build our fluency. The Miles Morales-es of our organizations are going to come in un-self-consciously fluent, and it behooves us as colleagues and potential mentors to be partners in that journey.

But That’s Not All

With a character history as rich as Spider-Man (not to mention a movie as awesome as “…Into the Spider-Verse”), it turns out I have a lot more to say on this subject. The adventure continues in the next issue.

Here’s an interesting blog about the need to keep a continued focus on security. I can’t agree more about training and security checks as a useful method of keeping staff on their guard. I’d add that an incident response plan is a useful and often overlooked part of the plan—which is now required for the feds.

November 30, 2018 marked the thirtieth annual Computer Security Day. Originally launched in 1988, the day was one of the earliest reminders of the threats facing modern technology and data.

Now, thirty years on, the threats facing organizations’ data are more significant than ever—from ransomware to hacking—while the sensitivity and volume of data grows each year. According to a recent survey conducted by IDC and Zerto, 77% of businesses have experienced a malicious attack in the past 12 months, with 89% of these being successful—demonstrating just how prevalent these security threats are. As Shannon Simpson, cyber security and compliance director at Six Degrees put it: “Cyberattacks have crossed over into the mainstream, and guarding against security breaches requires constant vigilance throughout your entire business, not just the IT team.”

The case for training

As security professionals, we are acutely aware of the tricks scammers may use—such as emails with fake bank details or ones made to look like they were sent from another company employee. However, it’s important to remember that not all employees are exposed to this on a regular basis. This is why experts strongly support ongoing training and education programs for employees to help empower them to avoid evolving scams.

Moving away from a fixed perimeter approach

A key factor in the move away from fixed perimeter security is the adoption of the cloud and the rise in cloud-based applications. Steve Armstrong, Regional Director at Bitglass, stressed that despite such applications making businesses more flexible and efficient, “many of the most popular cloud applications provide little visibility or control over how sensitive data is handled once it is uploaded to the cloud.” One of the primary vulnerabilities that Armstrong highlighted was the problem of misconfiguration such as in Amazon A3 buckets or MongoDB databases, pointing out that “given how readily available discovery tools are for attackers, ensuring corporate infrastructure is not open to the public internet should be considered essential for enterprise IT. To do this, Armstrong recommends that organizations should “leverage security technologies such as those provided by the public cloud providers,” all of which “provide visibility and control over cloud services like AWS.”

In addition, automation technology can help reduce the risk to data, both at rest and in transit, said Neil Barton, CTO at WhereScape. This is because “by limiting or negating the need for manual input, businesses can better protect against security vulnerabilities.” Meanwhile, using automation to take care of the basics can help free up IT staff “to ensure the data infrastructure is delivering results with security top of mind.”

The importance of testing plans and learning from mistakes

Providing IT staff with more time could be critical to one of the most vital aspects of security preparedness—testing. Stephen Moore, Chief Security Strategist at Exabeam, commented that “organizations that handle sensitive data must implement constant security checks, as well as rapid incident response and triage when needed.” This was a sentiment also voiced by Paul Parker, Chief Technologist, Federal & National Government at SolarWinds. Speaking about the need for cybersecurity in the public sector, Parker noted that “most important is developing and routinely testing your emergency response plan. Much like the UK’s Fire and Rescue Services practice fire response and life-saving services, organizations should also practice their network breach response.” His core advice to organizations in the current security threat landscape? “Don’t learn how to extinguish a fire on the fly.”

Finally, a sentiment echoed by several experts was the inevitability of organizations facing a cyberattack at some point in time. Gijsbert Janssen van Doorn, Technology Evangelist at Zerto, concluded: “Yes, protection is important; however, in a culture where attacks and downtime are no longer a matter of ‘if,’ but ‘when,’ these precautions are not enough. Organizations also need to be prepared for what happens after a disruption, and will be judged not only on keeping people out and data safe, but also on how quickly they are back to functioning as normal—how resilient they are.” Meanwhile, Parker concluded that, following an attack, “public sector organizations can use the insights garnered from the incident to learn, perfect, and prepare for the next one”—a sentiment as true for all businesses as those in the public sector.

Thirty years after the first Computer Security Day, it’s clear IT and security professionals find themselves in a much more complicated landscape than their predecessors. However, there is much that can be done to keep data safe, and businesses online—from moving away from the fixed perimeter approach to cybersecurity to ensuring regular training and plan testing, and even making sure organizations can get back online when something does, inevitably, go wrong. The key, across all aspects of security, is preparation.

I’m the Product Manager for our NetFlow Traffic Analyzer, and I’ve been working at SolarWinds for a little over a year. I’m excited about flow analytics and the problems we can solve by examining and visualizing network flow information. I’m awfully enthusiastic about all types of flow technologies, particularly traffic sampling.

I spend a lot of time talking about flow—asking customers about their challenges, and how they use flow data and tools in their environment. I also talk with my colleagues about flow. Sometimes, until they get tired of hearing about it. Often, even after they get tired…

At a recent trade show, our own “Father of NetPath”—Chris O’Brien—decided he would have a little fun, and he started a rumor that I was compiling a book of flow poetry. Naturally, this prompted me to begin writing flow poetry:

Every operations team has its fair share of monitoring solutions. While you may not have achieved the perfect state of a single pane of glass, you likely have settled on two or three solutions that cover all the hardware and software that supports your business. You even invested considerable time and effort to not just implement these solutions with out-of-the-box settings, but with tailored IT alerting thresholds and alarms that suit your environment’s specific needs. Look at you!

It’s easy to overlook the next step of your monitoring deployment: notifications. Usually, one of two things will happen:

1. You get too many alerts, and subsequently turn off alerts

2. You get too many alerts, and subsequently create an Outlook rule to trash them all

It’s the age-old signal-to-noise problem in IT. How do you fine-tune your notifications, so they alert you to events that deserve your attention while filtering out all of the notifications that are not actionable? Your first thought might be to turn off any performance-related alerts and just receive system or device down notifications. But if that’s all you’re looking to get out of notifications, you should just write a PowerShell script to run a Test-Connection against your server list and Send-MailMessage when a host is down. (That’s mostly sarcasm.)

Instead of throwing the baby out with the bath water, here are some monitoring and alerting best practices for reducing notification overload.

Inventory Your Applications

First things first: no one cares about your servers like you do. You invest countless hours building, installing, patching, backing up, repairing, and generally supporting these virtual beasts. Even if you’re running an automated shop (which you’re not), you still train your attention on the infrastructure. But the business cares about the applications.

So, if you don’t have a list of your apps (which should include URLs in this modern SaaS era), get one together. Without a reliable and accurate inventory, you’ll never know if you’re monitoring all your devices. (On a related note: if you’ve got tips on how to collect and maintain an application inventory, share them in the comments below.)

Map Applications to Devices

Now it’s time to correlate infrastructure with applications. In other words, if server org1east-c goes offline, what applications are affected? What if the NAS doesn’t survive a firmware upgrade? When you can draw direct connections between your applications and the infrastructure, you can shift the focus of your monitoring (and eventually notification routing) to the right teams as quickly as possible.

The benefit of this exercise is to tune your alerts and notifications to reach the right teams right away.

For example, if one of your load balanced web servers goes offline, you can have an alert sent to the server team to investigate the server. But don’t stop there. Also have an alert sent to the team that supports the website or app that relies on that web server. They may not need to take any corrective action, but they’ll certainly appreciate a heads-up that there may be infrastructure trouble brewing. And you’ll also avoid fielding calls from the web team asking, “What’s going on?”

Routing notifications isn’t the most exciting part of deploying a monitoring solution, because it’s likely the most difficult. Not because of the technology, but because of the deep dive required to really understand the connection between your applications and your infrastructure.

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining.

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website,
you consent to our use of cookies. For more information on cookies, see our cookie policy.