Architecting public sector organisations in a multi cloud world – Cirrus, Stratus, Cumulus – Part 1
Read More »
Fintan Galvin
9th March 2020
For product guidance visit
For product guidance visit
For product guidance visit
For product guidance visit
Basics of working in a Multicloud world is part 2 of a 5 part series.
In this post, Invotra’s CEO Fintan Galvin, discusses the value of adopting a hybrid cloud model and some of the factors that need to be considered and challenges you may encounter.
Fundamentally this is about who is responsible for what.
Dependent on your resources, abilities and strategies, you will choose which parts of your IT you want to manage and maintain / take responsibility for.
At a high level:
This is like old school hosting but with more control over the resources
Usually you have the ability to build, maintain and support stuff or
You might need this option for a business reason (e.g. competitive advantage)
You just want to use something everyday and not worry about it.
Who is responsible? | |||
IAAS | PAAS | SAAS | |
Application | You | You | Provider |
Data | You | You | Provider |
Runtime | You | Provider | Provider |
Middleware | You | Provider | Provider |
Operating System | You | Provider | Provider |
Servers | Provider | Provider | Provider |
Storage | Provider | Provider | Provider |
Networking | Provider | Provider | Provider |
Example commercial Services | AWS EC2, Google compute engine, MS Azure | AWS ML, Force.com | Invotra, Gmail, Salesforce, Trello. Webex |
Firstly, what is it?
Hybrid cloud is when you have an environment which spans on-premises infrastructure, private cloud services, and a public cloud.
Simply put, this is where you create a layer that sits over different environments allowing you to manage them as one IT infrastructure (in so far as possible).
There are many reasons for adopting a hybrid cloud model, the primary ones are below.
Reasons:
You have old systems that you are unable to currently migrate
E.g. you have an old cobol mainframe
You have systems that are starting, or are mid migration, to a full cloud setup
You have lots of capacity that you have previously purchased and want to keep it for as long as you can, to get value from the kit
You have certain services/data that you must maintain full control over for legal, security or compliance purposes.
Most companies are in the 2nd category. Using a hybrid cloud model offers huge value in allowing you to develop your overall capabilities while taking on the often arduous task of migrating.
This is an area fraught with danger.
It is very common these days, and all too easy, for people within organisations to sign up to SaaS applications without company approval – all they need is their bank card. There used to be more control in terms of what software could be installed but now many applications do not require installation to use them, and even if you block access they can still use personal devices.
Provide clear guidelines, procedures and governance
Don’t think you can stop this completely, very few organisations can achieve this, rather develop the ability to handle it
Educate people to understand the problems and issues this can introduce
Regularly ask people what they are using and make it easy for them to let you know without fear of being disciplined
Remember they are trying to get a job done and whatever the app does is clearly solving a business problem. Help them find an alternative.
Put together a simple list of key elements that people should check when selecting an application and make help available to them.
When we think about dependency management, we usually think of project plans or dependencies within systems. Here, we are focused on dependencies between systems in a broader sense.
This is an area that needs special attention in a multi cloud environment. Services such as SSO are obvious, however, with the proliferation of APIs (especially within a cloud application world) it’s incredibly easy to tie systems together.
While this is fantastic, it also means that people can create critical dependencies between systems without the IT department knowing much, if anything, about why this has been done. So, what seems like a simple change can have a massive impact across the business.
The key to managing system dependencies is to have accurate reporting on your APIs and to understand who is using them and why, combined with a clear policy around versioning of APIs.
One particularly difficult area to deal with is use of middleware solutions like Zapier/Flow. These solutions essentially hide what the API is used for. They are often fantastic solutions but bring with them an additional level of obfuscation that is difficult to manage.
Service models have dependencies that we also need to worry about. Each system has its own ecosystem that keeps it alive and you’ll want to make sure that these are all working together to deliver what the business needs. Frequently, service agreements can be changed (with the exception of enterprise) with minimum notification to clients – and even those who are notified may not even fully understand the complexity of the support ecosystem.
We live in a fantastic world of choice and simplification.
However, you need to make sure that it is managed properly from the beginning. It is imperative to have teams that cover Architecture, Compliance, Security and Service with a common view of the ecosystem that you want to end up with.
Basics of working in a Multicloud world is part 2 of a 5 part series.
In this post, Invotra’s CEO Fintan Galvin, discusses the value of adopting a hybrid cloud model and some of the factors that need to be considered and challenges you may encounter.
Fundamentally this is about who is responsible for what.
Dependent on your resources, abilities and strategies, you will choose which parts of your IT you want to manage and maintain / take responsibility for.
At a high level:
This is like old school hosting but with more control over the resources
Usually you have the ability to build, maintain and support stuff or
You might need this option for a business reason (e.g. competitive advantage)
You just want to use something everyday and not worry about it.
| IAAS | PAAS | SAAS | |
| Application | You | You | Provider |
| Data | You | You | Provider |
| Runtime | You | Provider | Provider |
| Middleware | You | Provider | Provider |
| Operating System | You | Provider | Provider |
| Servers | Provider | Provider | Provider |
| Storage | Provider | Provider | Provider |
| Networking | Provider | Provider | Provider |
| Example commercial Services | AWS EC2, Google compute engine, MS Azure | AWS ML, Force.com | Invotra, Gmail, Salesforce, Trello. Webex |
Firstly, what is it?
Hybrid cloud is when you have an environment which spans on-premises infrastructure, private cloud services, and a public cloud.
Simply put, this is where you create a layer that sits over different environments allowing you to manage them as one IT infrastructure (in so far as possible).
There are many reasons for adopting a hybrid cloud model, the primary ones are below.
Reasons:
You have old systems that you are unable to currently migrate – E.g. you have an old cobol mainframe
You have systems that are starting, or are mid migration, to a full cloud setup
You have lots of capacity that you have previously purchased and want to keep it for as long as you can, to get value from the kit
You have certain services/data that you must maintain full control over for legal, security or compliance purposes.
Most companies are in the 2nd category. Using a hybrid cloud model offers huge value in allowing you to develop your overall capabilities while taking on the often arduous task of migrating.
This is an area fraught with danger.
It is very common these days, and all too easy, for people within organisations to sign up to SaaS applications without company approval – all they need is their bank card. There used to be more control in terms of what software could be installed but now many applications do not require installation to use them, and even if you block access they can still use personal devices.
Provide clear guidelines, procedures and governance
Don’t think you can stop this completely, very few organisations can achieve this, rather develop the ability to handle it
Educate people to understand the problems and issues this can introduce
Regularly ask people what they are using and make it easy for them to let you know without fear of being disciplined
Remember they are trying to get a job done and whatever the app does is clearly solving a business problem. Help them find an alternative.
Put together a simple list of key elements that people should check when selecting an application and make help available to them.
When we think about dependency management, we usually think of project plans or dependencies within systems. Here, we are focused on dependencies between systems in a broader sense.
This is an area that needs special attention in a multi cloud environment. Services such as SSO are obvious, however, with the proliferation of APIs (especially within a cloud application world) it’s incredibly easy to tie systems together.
While this is fantastic, it also means that people can create critical dependencies between systems without the IT department knowing much, if anything, about why this has been done. So, what seems like a simple change can have a massive impact across the business.
The key to managing system dependencies is to have accurate reporting on your APIs and to understand who is using them and why, combined with a clear policy around versioning of APIs.
One particularly difficult area to deal with is use of middleware solutions like Zapier/Flow. These solutions essentially hide what the API is used for. They are often fantastic solutions but bring with them an additional level of obfuscation that is difficult to manage.
Service models have dependencies that we also need to worry about. Each system has its own ecosystem that keeps it alive and you’ll want to make sure that these are all working together to deliver what the business needs. Frequently, service agreements can be changed (with the exception of enterprise) with minimum notification to clients – and even those who are notified may not even fully understand the complexity of the support ecosystem.
We live in a fantastic world of choice and simplification.
However, you need to make sure that it is managed properly from the beginning. It is imperative to have teams that cover Architecture, Compliance, Security and Service with a common view of the ecosystem that you want to end up with.
Coordination of service wrappers
Reporting
Change Management
Configuration management
How to deal with all the different upgrades / updates
