top of page
bacckgroundcover123.png

Process Tempo Insights

  • striveon

The Challenges of Cloudification: How to Ensure a Safe, Manageable, Cost-Effective Cloud Strategy

PART I - THE CIRCUS

Just now discovering our Blog Series? Get caught up with The Challenges of Cloudification: Series Introduction and check out our Series on Business Continuity Planning In The COVID-19 Era

 

While the cloud services aura can lull departments into thinking the cloud is a comfortable place to host and accelerate services with a quick, low, and affordable price of entry, there is more to the process to ensure a safe, manageable, and cost-effective cloud strategy.




Three core areas can prevent a cloudification strategy from realizing it's full value:


  • The high interdependency between cloud microservices and those who build the services (we'll call this the "elephant");

  • The demand for constant improvement and efficiency (we'll call this the "gorilla");

  • Manning an inventory of hundreds or thousands of microservices running in a cloud environment (the "pets")


While Cloudification does allow for flexibility in size, scale, locations, vendors, and technology, it is this same flexibility that allows the space for these three core areas to arise.


So with the circus in town, how should organizations go about managing their cloud environment?


In this post, we'll be breaking down each of the core three areas, highlighting pain points and solutions, and identifying the data you will need and the questions you should ask when beginning to establish your safe, manageable, and cost-effective cloud strategy.



1) THE ELEPHANT IN THE ROOM


As with traditional IT, cloud-based microservices, apps, and APIs are coupled with the people that created them. While developers often intend for their creations to be portable and easily understood, they often end up building microservices that:

  1. Are not easily understood by other teams;

  2. Lack flexibility to be more broadly applied; and,

  3. Lack observability into security, reliability, and uptime

Often, development teams find it easier to create their own microservice rather than reuse an existing one. This practice rings especially true when developers who created the original systems have left the company.


This overall notion - the high interdependency between cloud microservices themselves and those who build the services - is the significant elephant in the room.




2) "IT'S LIKE WRESTLING A GORILLA. YOU DON'T QUIT WHEN YOU'RE TIRED, YOU QUIT WHEN THE GORILLA IS TIRED" - Robert Strauss


In Cloudification, the gorilla represents the demand for constant improvement and efficiency. It is mainly present in the struggles between:

  • Speed and agility vs. maintaining hygiene and safety

  • Keeping environments secure, cost-effective, and lean vs. operational tasks

  • Staying ahead of new feature releases vs. preventing outages

The key to taming the gorilla is to possess two elements: an accurate inventory of what exists within the cloud environment, and the ability to make plans using that inventory for keeping the environment modernized and robust.


Checking these two boxes reduces the time spent in reactive mode, consequently allowing for more proactive measures and ultimately ensuring greater flexibility, room for innovation, and better internal understanding of the environment.




3) THE FAMILY PET

In Cloudification, the family pet represents Microservices, the adorable routines that go on running day in and day out. The family pet is present, dutiful, and fun - as long as they get the care and feeding they need. They have an uncanny ability to occasionally misbehave and cause chaos at just the right time. Family members can face disruptions with paused or canceled plans unless appropriate care can be ensured for their pets.

Similarly, Microservices can be anti-patterns to keeping pace with changes occurring in the business, with fragile and undocumented microservices making it more difficult to modernize.


Microservices can be anti-patterns to keeping pace with changes occurring in the business, with fragile and undocumented microservices making it more difficult to modernize.

In legacy IT, pets were the physical services with apps running on them, continually fed both power and cooling. Today, these devices have been replaced by far less tangible microservices, often requiring subscription fees. There is no clear path away from them.

These legacy pets were servers installed within data centers and were easier to address when someone could walk the floors and ask questions about each server. Inventories tied back to capital expense PO's, and devices could be flagged or even have their network cables unplugged to test the results.

Now, creating or manning an inventory of hundreds or thousands of microservices running in a cloud environment is increasingly difficult. Even with a list of APIs and their usage profiles, the cost of one may only equate to a few hundred dollars a month - something many teams don't take seriously enough.

Typical IT teams and the business units that sponsor them don't see these microservices with smaller-dollar costs as worth their time to address. They can be inexpensive enough that it can be easier to keep them around - until there's suddenly hundreds or thousands of them running amok.


Typical IT teams don't see these microservices with smaller-dollar costs as worth their time to address... they can be inexpensive enough that it can be easier to keep them around - until there's suddenly hundreds or thousands of them running amok.

 

The Key To Managing The Circus:


The benefits of cloudification come with some pressing issues that can compound difficulties if left to their own devices. Organizations are currently facing an environment inundated by:

  • Hundreds of microservices, lambdas, and storage subscriptions

  • A dizzying array of costs

  • Security attack vectors

  • A piling up of technical code debt

The key to managing the circus is to start by having useful, reliable data about the microservices.


The key to managing the circus is to start by having useful, reliable data about the microservices.

 

THE DATA YOU NEED, AND WHERE TO START:


If you are entering the microservices world, building an inventory system first and foremost will make the entire job more manageable. If you're more experienced with microservices, either plan to put a team in place or consider engaging professional services to collect and categorize your microservices for you.


While the complete list of all the data you could need would fill volumes and change over time, the basics include the following:



CRITICAL: COLLECT DATA FOR YOUR MICROSERVICES TEAMS

  • Who manages and is responsible for the microservice?

  • Who is the technical leader that can answer technical and operational questions about the microservice?

  • What does the microservice do? Is it doing it?

  • How is the microservice built?

  • Does it contain PII or access systems that have PII and other private information?

  • Does it have sufficient security controls? Who can access it? How can it be accessed?

  • Does the service or the cloud hosting environment have ciphers of sufficient strength?

  • Are SSL, mTLS and Bearer Tokens private and secure?

  • Are there any hardcoded secrets?

  • How is the microservice accessed, only Internally, externally, or both?

  • What backends does it access, and are they external, internal or both?


CRITICAL: TIE IMPORTANT BUSINESS DATA TO MICROSERVICES DATA

  • Who are the customers of this microservice, and what is at stake for your business relationship with them?

  • Do you have expressed or implied Operational Level Agreements, error budgets, and availability targets?

  • What is the commercial value of these microservices to your business?

  • What is the cost to run and improve these microservices?


 


BALANCE RECOMMENDATIONS WITH REALITY


You may not have the budget or the people available to collect all this data at once, so you will need to aggregate the data in a searchable database and tag that data with a freshness date. This is not a job for spreadsheets - consider using a purpose-built platform or service to help with cataloging your microservices. It will help you evaluate compliance.


This is not a job for spreadsheets - consider using a purpose-built platform or service to help with cataloging your microservices... You will likely encounter various problems and questions that can only be answered by seeing your entire environment at a summary level.

You will likely encounter various problems and questions that can only be answered by seeing your entire environment at a summary level. As your portfolio grows, the issues you see on one microservice will likely exist on others and may be a symptom of another problem you have yet to discover, much less actively mitigate.

You will also need a strong system of record to log configurations, contacts, changes, and other information that will help you manage the environment.

To gain the full value from this effort, you will need a team to operate at the enterprise level to manage and enforce standards and take responsibility for the shared environment as a whole. Do not expect individual teams, software architects, software engineers, or developers to spend much - if any - time outside of their development focus.


You need to know your environment. Every actor in the circus needs to be understood. It should come as no surprise that your teams' actions or lack WILL continue to be the largest elephant in the room.


Allow your organization to provision with supervision. Guidelines will help to avoid overwhelming problems far greater than the proliferation of servers on a raised floor.



FINAL QUESTIONS TO ASK YOURSELF:



How well are you able to track compliance with the microservices created or consumed by your organization? Are the actions of your microservices in line with the design intent and company policy? How robust is your knowledge about essential microservices details?


Perhaps it is now time to take a closer look at how your data is working to keep your cloudification approach strong, your employees focused, and your operations cost-effective.



 

Jim Szczygiel has been working as an Information Technologist since the early nineties. Most recently, Jim has held roles as a consultant, product manager, data analyst, sales, and solutions architect along with working with agile and extreme programming teams. Jim has provided services to hundreds of different fortune 500 clients in the sectors of Chemical and Natural Resources, Finance, Insurance, and Manufacturing. Read More



bottom of page