I said I’d post this “tomorrow” in my last post, and it definitely has been several “tomorrows” since then (mostly because I’m lazy and busy, which is a terrible combination), so let’s recap:
This series of articles revolves around:
- The reasons why packaging any software used in your project’s environment is important.
- Service management considerations for your software on the Linux operating system.
The approach we’re taking emphasizes where this would take place in the
SDLC, specifically the
ALM (Application Lifecycle Management) which I encourage you to read up on if you’re not already familiar with these entrant software engineering concepts.
To do this, we’re removing all the coding, all the solutions architecture and design out of the software engineering process so that we can look at just these two aspects — and the example that we’re using is an HTTP echo service that I’ve hacked out of a very simple HTTP server in C++ with the
boost library to create something called a
microservice if you’re familiar with
SOA (Service Oriented Architecture).
These are all suggested
google search terms.
But first, what genre is this even?
Anyway, to bidness, some patterns and antipatterns as it pertains to package management (I’ll be breaking this into cleanly organized content when it’s all laid out btw), I’ve started some crude graphs that demonstrate what I’m actually saying to be used in a more meaty article later.
Package Management Is a Fundamental Best PRactice
First, we’ve concluded that packaging your software is an intrinsic result of abstraction of software to units on your system using a simplified representation of parts of the OSI model:
Service State Management Patterns and AntiPatterns
Variant A and B
Examples A, B and C
Given the amount of research it takes to justify the reasons why sysadmins are trained to do this in this way, I’ll need to spend more time on the meat of the article and will end up condensing this whole series into a whitepaper. But for now, I need the rest of my Saturday.