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. 

Evolution of DevOps

Evolution of DevOps

Why DevOps is a digital state of mind...

I have chatted many times with experienced engineers over the years who frankly see DevOps as being CICD for engineers who can talk to software developers. This is understandable considering something new is dropped into old management practices with a company culture that sees DevOps as nothing more than tech types creating a trending new tech addition to the existing company structures. Many now realise that if a company is to succeed in the digital marketplace, it must have a consistently effective product team instead of multiple functional teams handling software products. This means the days of functional based technology problems where it is a 'Software Dev's problem' or 'an Operations problem' will eventually be gone from the digital landscape. This evolution has led to the modelling of CALMS in the spirit of the evolving DevOps paradigm. For those who embrace a collaboration orientated culture that does not chuck problems over the organizational fence, CLAMS is a breath of fresh air that takes DevOps to the next level. So let's look at CALMS and it down as follows:

  • Culture - the move to an adhocracy dominated company culture driven by a change in leadership practices is the number 1 requirement for implementing CALMS in my view. Design and feature discussions, software development standups, build meetings plus more are examples of events that operations engineers have traditionally not been invited to as they are not within the scope of the operations area of competence. Correspondingly, ever try to get a developer at 3am after triaging a major outage, which points to a software issue? Cultural alignment must be cross-functional across the company and align without exception all the way to the top for it to be a success. This requires a paradigm shift for the company, which in turn requires an enormous amount of planning and investment by management to make it happen.
  • Automation - CICD, integration, and continuous improvement in a data driven manner to increase product performance is the focus here. Here one can also see the culture shift to cross-functional team problem-solving noting the wider lens creates new areas of importance. For example, production support for runbook based curation rather than tribal knowledge reliance becomes a priority as one cannot scale in a manner minimizing mistakes and custom treatments of problems without guidance from the documentation around what to do and when. Automation of deployments in a manner that is reusable will lead to a shorter time to deploy and strategies for fixing mistakes like automated rollbacks instead of 'hot fixes'.
  • Lean - Despite multiple takes on the word 'Lean' in business, this DevOps based meaning is based on the concept of risk acceptance around failure. The concept of its ok to fail along with the realization companies need to become failure resilient, not failure sensitive in their outlook is covered here. This cross-functional approach opens a lens of structured failure response quickly followed by learning and recovery. The learned lessons from lean are shared organization-wide so all interacting functions of the digital product know about what happened and the lessons learned from fixing it. This cross-functional awareness can bring help from unexpected quarters dismissed as not possible in times past.
  • Measurement - In order to become closer to the company in an adhocracy driven culture, the need to embrace technology to measure everything that is done is critical to data-driven decisions in the software development lifecycle delivering meaning to every decision. This in turn relieves the reliance on politics and personal bias at critical decision making junctures.
  • Sharing - Sharing failures as much as wins become accepted as normal practice in a culture that looks to learn from its mistakes instead of pointing fingers. Correspondingly, wins no longer rank as a cultural baton to beat competing functions up with in meetings. Gloating and brinksmanship switch from being a cultural virtue to a cultural vice.

This evolution of DevOps has also roots in the compatible agile project management methodologies that facilitate this pan company approach to digital projects. This of course makes sense of course. After all, why would a digital company approach it any other way? 

Stay tuned for more on 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!

Best Regards

John 

Another Maolte Milestone

Another Maolte Milestone

Full-Time Contracting Announcement

We often look back on our milestones in life. Now is the time for one of those hallmark moments on my journey by writing this article. Maolte up until now has been a freelance concern for my sole trading activities offering many services and acting as a vehicle for assessment of what works in the marketplace for my initial service. After careful research and assessment of the marketplace, I have decided to spin up my own limited company bringing my initial service offering into my limited concern with the exception of novel writing. I shall retain my aspiring novel writing as a freelance concern so do stay tuned for more on that also. 

It gives me great pleasure to confirm the service offering I launched on my freelance website last October at https://maolte.ie/services/ shall form the initial service offering as a contractor when my limited company is spun up in the next 4 to 6 weeks. The range of services currently on offer falls are as follows:

  • CI/CD  Deployments and Hosting 

  • Cloud Production Support

  • Technical Project Management

  • Programming and Automation 

  • Cloud-Based Systems Design 

  • Infrastructure Production Support (Servers/Services/Troubleshooting/Routers & Switches)

  • Customer Support 

  • Technical Root Cause Analysis

  • Major Incident Management

  • NOC Deployments and Hosting 

  • Technical Event Management

  • Event Writing and Reporting (Technical and Non-Technical)

  • Technical Writing (Runbooks/How To Documents/Customer Facing Documentation/Technical Analysis Documents e.g. TRCA Report)

  • Commerical Writing (Technical/Business)

I am due to finish up with Sage by month's end with a busy schedule of project completions and handovers knowing I am leaving the team in good stead for the continuing success story that is Sage. My own journey will look to help you on yours so if you are in need of the above, do reach out via john@maolte.ie and let me know how I can help you write another successful chapter in yours.

Stay tuned for more on 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!

Best Regards

John 

SaaS and the Digital Revolution

SaaS and the Digital Revolution

Why cloud migration to SaaS requires more than Data Transfer

In 2017, I remember in college when completing my Associate's Degree in Computer Science how hamstrung the definitions of IaaS, PaaS and SaaS were. Our lecturer explained how leading industry experts were disagreeing over definitions and standardisation with divergent technologies competing dysfunctionally for the hearts of the B2B customer in a relatively small digital marketplace compared to now. After COVID, it is very obvious that the explosion of the cloud industry to facilitate the digital boom has seen the cloud industry grow at an unprecedented rate. Everybody wants to migrate to the cloud!

The scalability problems solved by the cloud platform providers alone are an incentive for conventional businesses to heavily invest in migration into the cloud. After all, companies who are creating migration plans and executing them to see their prior capital investments in IT turn into a tax efficient operational expenditure for the 21st century is how it is done, right? Well, partly right is the best answer I can give. The migration and on-prem data centre decommissioning processes are becoming more refined literally with practice. The standing assumption however by many management teams in the successful migration project to the cloud is the digital products they had on-prem can be maintained and developed in the same way in the cloud. This can prove to be a costly mistake to rectify depending on how quickly the team can learn from their mistake and pivot their strategy to recover and take advantage of what the cloud has to offer.  A fuller risk analysis of a cloud migration project in the project discovery phase can reduce risk by getting a clear vision of how the business's technology and people work before they migrate to the cloud. The discovery phase in addition to assessing the technical requirements of architectural and data compatibility should answer the following:

  • How is the software implemented by programmers, what coding patterns are used and are they compatible with modern cloud-native products and practices? Application software built with no real segregation of concerns between code and data for example is not a good fit for the cloud. A rewrite would be required in this case.
  • How is software architecture designed? Does it embrace modern orchestration products on a logical layer (server) or still embed in physical servers on a 1:1 basis. 
  • Does on-prem infrastructure reflect highly available patterns with the use of logical server pools, load balancing and internal firewalls or is it a simple one server design?
  • How is software supported? Is there a culture of technical support when it stops working and someone complains or is there sophisticated monitoring tools and infrastructure in place on-prem?
  • Are any on-prem monitoring and remediation actions automated?
  • What kind of company culture does the company have? Is it closer to the customer or closer to the employee? Does it trust employees to act or does it direct employees to act? Is one group favoured culturally at the expense of the other groups creating in-groups and out-groups?

These are some key questions to ask that may identify risks and help avoid costly mistakes post a 'successful' migration to the cloud. Cloud migration is not the standard 5-year strategy shake up for most conventional businesses. It is a paradigm shift in technology standards, technology practices and company culture that can go horribly wrong if the whole migration to the cloud is not in scope for the project. To be a SaaS company is more then a cool title, its a closeness to the customer that is unprecedentedly requiring every employee including engineers to act in the same cultural space allowing technology adoption and projects to be a centre piece in the working day knowing SaaS companies live and die by their ability to embrace the customer through its available technologies. 

Stay tuned for more on 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!

Best Regards

John