Thread by @shehackspurple

#minilesson The difference between applications and infrastructure;

Infrastructure is the operating system that applications live on. Think windows, linux, containers, and so much more. Sometimes hardware is included in this category (depending on who you talk to).

Infrastructure is necessary to run an application. Operating systems are also all standardized, not unique in nature. If we’re both running SQL server 2012 R2, we both have the same options for patches, configuration, etc. Operating systems are software that speak to hardware.

Applications are software that speak to operating systems, databases, APIs and anything else you can think of. There are custom applications (what I’m almost always talking about, software developed for a specific business need or as a product to sell), COTS…

(configurable off the shelf, like sharepoint or confluence, administered by a person or team, installed locally on a server) and regular old software that you install or access via a web browser that you use as-is (no administration required/simpler).

More newly there is SaaS, software as a service, which is basically a great big COTS product, hosted by someone else ( no need for you to patch or otherwise take care of it).

Infrastructure usually needs to be patched, updated/upgraded, and hardened (secure configuration choices). Patches and upgrades arrive in a prepackaged format, but sometimes these updates can break the applications living on that infrastructure.

Testing and sometimes downtime is required. This is why so many people say ‘patching is hard’, it is difficult to plan downtime and to ensure everything will go smoothly.

Software, on the other hand, includes many different components that will be provided prepackaged (such as a new version of a library or a framework) but when you update them sometimes other libraries or framework parts break and/or the custom code that your team wrote…

Meaning you may need to recode things, or update a whole bunch of things at the same time. I’ve heard developers refer to this as “dependency hell”. I can’t say that I disagree.

If you have just released something brand new, it’s super easy to keep it up to date. Tiny changes are less risk (which is why people live devops over waterfall), making it easier to maintain. But because it’s sparkling and new…

Usually management says “hey, please build this new feature, and update that library later”. This is how technical debt accrues. It’s not operational staff or software developers saying ”forget that, I don’t care about this “, it’s almost always conflicting priorities.

This is part of why I believe devops is so good for security: finally we can patch, update and test EASILY for the first time.

If you’re process for patching or releasing software is total hell, THAT is your security problem. Not some zero day that’s in the news this week.

Questions? 😁 Thanks for attending my mini lesson.