Blog

Blogs

Blog article category for blog articles on this site covering the areas of DevOps, Cloud Infrastructure, Site Reliability, Technical Writing, Project Management and Commerical Writing along with Event Management and associated areas. 

Major Incidents and Digital Migrations

Major Incidents and Digital Migrations

As more and more businesses are moving into the digital world, they search for the best and easiest adoption strategy that often points to the cloud. Many cloud migration projects have a bear-bones approach to getting existing digital infrastructure onto the cloud called a lift and shift. New entrants may adopt a strategy based on their ‘IT guy’, whose real expertise is in Windows and maybe Mac operating systems and hardware.

Even with cloud experts at the helm, the cloud migration project can be reasonably well formed and still miss major incident management on the process side of infrastructure management after the project. So why should it be an issue? Picture a successful deployment to the cloud, which meets the non-functional requirement of scaling. Whilst all will be well at the current customer usage level, scaling infrastructure over time leads to two risks. Firstly, what happens if your scaling infrastructure depreciates product performance as it scales? Will it impact your customer retention rate? Secondly, the larger your infrastructure the more likely it will fail. This will count down to certainty over time. What is your plan to deal with an outage?

SRE practices have a culmination of learned lessons leading to some guidelines when thinking of migration to the cloud or into the digital world. The following should be borne in mind when thinking of a digital migration project in terms of non-functional project requirements.

  • Does my company have a major incident management process and is it up to date? Is it proven effective to deal with major incidents in a manner that scales by process versus tribal knowledge offered by a few select engineers?
  • Is scalability a requirement of the project and if so, will the major incident management process be updated to reflect the new digital reality in the post-project stage?
  • Even if my new architecture post project is highly available, do I have the technical staff and resources to effectively manage major incidents across the full stack in line with my major incident management process? Does it focus on process steps to define the problem/root cause, mitigate the outage and resolve the incident? Is there a follow-up stage to mitigate the risk of it happening again (aka. root cause analysis)?
  • Is my migration project at least checking if not providing for appropriately trained technical staff to manage an effective major incident process in operations and/or security?
  • If my intent is to scale quickly, do I have separate major incident management processes in place or a plan to put them in place for both operations and security?
  • Do my major incident processes report on key metrics like ‘time to detect’, ‘time to report’, ‘time to mitigate’ and ‘time to resolve'?

The timeline of every major incident impacts a digital brand over time. End-state processes like this are a wise longer-term requirement in any digital migration project. There are a vast amount of known practices and development points that deepen and widen the success of a cloud migration project after it closes. However, the best cloud migration projects can only be enhanced by a step/cycle that evaluates and/or implements a major incident management process based on the project’s requirements for the new digital infrastructure. Stay tuned for more on Cloud Infrastructure in this blog along with articles on other areas of interest in the Writing and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

DevOps Agility and the Digital Services Act

DevOps Agility and the Digital Services Act

The EU’s fight against disinformation and online safety for its citizens just ramped up with a solid response in the form of the Digital Services Act. It seeks to address the exploitive risks our citizens are exposed to in an online setting, which includes the seemingly feral yet organized spread of disinformation. For the tech industry, this means some internal adjustments to its compliance team with a more substantial augmentation of its digital compliance program. The act opens in clause (1) with “Information society services and especially intermediary services have become an important part of the Union’s economy and the daily life of Union citizens”. All national laws around digital safety are complimentary to this EU-level act, which brings in new compliance structures along with clear and piercing enforcement powers.

We techies need to be responsive in the DevOps field around agile deployments given the need for speed in remediation actions. Non-compliant companies can be fined up to 6% (Article 52, section 3) of their annual worldwide turnover, which gives teeth to the EU’s new act and commercial priority to any remediation actions required. First and foremost, the changes required may not be only in the application layer where interactive algorithmic changes are executed, changes may be required at the infrastructure layer also. We engineers can be a sentimental lot that loves what we get working and thus can be slow to change. This is a mindset that can present security risks on an ongoing basis, which includes dogmatism around larger-scale changes such as architectural changes impacting our infrastructure.

Let's look at a use case that requires a well-prepared and skilled approach for an agile-based response. If you support an interactive (dynamic) website that hosts interactive digital products and has an architecture that has not been revised since 2014, how do you ensure your sensitive data content is not been compromised in its submission and storage? If this cannot be clearly answered, architectural solutions that temporarily house and analyse data payloads for sensitivity comes into scope. An example solution would be (on AWS) a well-architected framework having a gateway account for data processing at the boundary to the internet. This account would house S3 storage instances and AWS Macie managed service to do the sensitive PII data analysis before sending the processed payload internally to its final storage destination in another AWS (internal) account. Making this happen is where DevOps comes in.

Some things to think of when faced with the challenges presented in remediation requirements for compliance under the Digital Services Act.

  • Segregate pipeline projects (or pipelines) in your tool of choice (e.g. Jenkins, Azure DevOps, AWS CodeStar) to ensure a bottom-up approach is enforced via segregation of concerns. Make sure your service connection tokens/service principals are identifiable for their unique purpose (e.g. deploy infrastructure, application, etc).
  • Do your deployments as sequenced sub-steps in an overall agile project where you iterate your infrastructure changes first (e.g. new account from AWS organizations, then provision s3s, AWS Macie with compliance spec requirements, then repoint edge gateways). Then iterate with application level changes in line with requirements (e.g. algorithmic changes), etc.
  • Ensure your pipelines conform to best practices with secure secrets management, and no exposed data in transfer (or at rest) when operating your CICD tools.
  • Jenkins requires more configuration given its narrow modular design. Managed cloud CICD tools have an advantage with their cloud-native managed service relieving the engineer of a great deal of system administration when setting up their CICD projects. If you don’t know Jenkins intimately (and it's fun to learn by the way), then go with your cloud-native CICD tool of choice.
  • Agile project management is best served in general terms by projects that are planned in an iterative approach prefaced with a ranking by critical path and risk. If you think there is a lack of guidance on priority and logical sequencing of steps in your project then speak up. Doing so before the project starts will do your company a huge favour in identifying missed risks. If nothing else, clarification received will leave you in a more informed position entering the project and working forward to a successful outcome.

There is no doubt that the CALMS DevOps model will become more and more important to all digital companies that rise to the challenges presented in this technological era. Companies who adopt it in their move to become closer to their online customer will see agile DevOps practices becoming the norm and not a project requirement in remediation. This paradigm shift may start with a pressured nudge from a regulator, but if responded to correctly can lead to a new era in your digital business's viability, competitiveness and vitality for the longer term.  Stay tuned for more on DevOps in this blog along with articles on other areas of interest in the Writing and Cloud Infrastructure arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

New Business and IT Contracting

New Business and IT Contracting

“Surround yourself with like minds and you will do great things”

This November makes it 6 months after the initial vendor meetings pre Maolte’s launch. It also is 4 months after Maolte’s incorporation and nearly 1 month after the last of the critical cards on my company setup (kanban) board was completed. In reflection over this transitional stage in my company’s journey, the heavy payload of problems dogging efficient set up and launch led me think about the learned lessons from this stage. This has yielded the following insights for all those who are new to contracting like myself and are as follows:

Start with the end in mind

Decide what you want from your contracting venture and break down into real detail. Is it technological advancement without the permanent employee distractions? Do you have a great idea for a digital product and want to develop it? Are there other pursuits you want the freedom to pursue like writing books, or maybe teaching part time? Keeping your goals real is the first successful step you will take. 

Sole Trading, Umbrella Company or Limited Company

Sole trading provides a streamlined vehicle for any activity that does not expose you to much risk (e.g. novel writing), nor perform a repetitive and/or existing task that would emulate a permanent employee role. For contractors with a ready pool of clients, maybe the temporary nature and expediency of an ‘umbrella company’ would suffice for short to medium term work requirements e.g. IT projects or service provision. If you see a longer term future subject to a successful launch, then investing in a limited company to ‘build your business’ like I am doing maybe a better fit for you.

Fund your start up phase

Money is a big concern for us all, so detailed financial planning on your business outlay and your personal outlay is required. Be prepared to fund your business for a defined period of time to allow you to achieve a milestone where your business will generate revenue from its activities. You need to be able to pay yourself before this project phase/stage ends.

Structure your start up professionally

Evaluate the best project management methodology (Kanban/Waterfall) to use in your project launch and use an effective project management system like Jira or Trello to manage your progress. Staying on top of numerous moving parts as a sole member company is difficult. Automated tools are a true aid in staying afloat of your work schedule during your start up project. They also help with management of a work life balance in this hugely pressured and busy phase of your professional life.

Vendor selection should reduce risk, choose your vendors wisely

Smooth talking sales pitches are great, but they also exposure you to missing details of why you need your vendor onboarded for your new business. Think about the key aspects of what you want any vendor to do in terms of the service components they provide, along with how they provide it in technology and human terms. Its a mistake to ignore culture. Deliver to a candidate that you have invited into your tender process the type of interfacing business practices you expect as a client in terms of communication, service levels, etc. A template of points/questions to cover on each vendor selection process is a good idea to set the agenda for discussion. Its also useful to rank your candidates based on the interactive points you raised. In your ranking structure, the addition of a cultural point based on your ‘feeling’ of compatibility will increase your chances of success with your vendor. Like minded vendors are crucial to your success in setting up as a new business.

Set up business plans and processes for marketing, business & technology development

As a technologist and engineer, I totally understand the position of my fellow engineers who see contracting as a vehicle for their existing skillsets been sold for a set term. There is nothing wrong with this position, which is one of the reasons why Umbrella companies exist. If you want to build something with the potential for a longer term view like I am doing, the setting up of processes to get your name, brand and reputation out there is very important. Also as important, is the development of that position you have gained in the marketplace by maintaining and developing on the quality of your work.

The biggest change after leaving permanent employment as an engineer is the loss of that daily, weekly and monthly structure. Its important to continue to manage stress levels via good living, exercise, etc. It won’t be long before a huge payload of work will need to be structured that will replace what you lost. Your decision to move into contracting may succeed or fail but if you don’t try, you will never know. Good luck to all who dare to try and respect to all who do. Stay tuned for more on writing in this blog along with articles on other areas of interest in the DevOps and Cloud Infrastructure arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!