When starting a cloud journey, many CIOs rightfully look to a set of IT principles in guiding their implementation. One commonly used IT principle is avoiding technology lock-in. There are many reasons why this is a good principle to uphold. Relying too much on one single vendor, for example, is very risky because you typically don't have control over the vendor's product direction and company health. However, committing to a single technology or vendor is not always heresy, depending on where you are in your cloud journey.

Agility

There are many goals for moving to the cloud, and agility is arguably at the top for most companies. Agility in execution requires simplicity which is much easier to achieve through uniformity and standardization of technology.

Serverless technology is an example that captures this problem. On the one hand, deploying your workload as serverless would allow you to focus on your application and help you be more agile. On the other hand, building your application for a proprietary serverless technology would lock you to the cloud service provider's ecosystem. If you come to this scenario, assess whether committing to the ecosystem would give enough competitive advantage, that sacrificing technology independence is worth the cost.

Operational risks

Let's look at an example in application monitoring, which is basic hygiene for your IT operations. Most cloud service providers offer an in-house tool for monitoring, and if you have adopted AWS, you would be using Amazon CloudWatch. In most cases, CloudWatch just works with little or no setup. The trade-off, of course, is that it doesn't work outside of AWS.

If you're operating a multi-cloud environment, your IT operational tools must work across different clouds. This usually means that you must stand-up some cloud-agnostic tools on your own. For example, instead of standardizing on CloudWatch, you might set up a Syslog server. Besides the additional effort, this requirement would make your IT architecture more complex and introduce more “points of failure,” which would increase your operational risks.

Cost considerations

Another IT principle to consider is the total cost of operations. Let's look at the cost implications using the examples I provided above.

Depending on the type of your application, a serverless implementation could be more economical compared to a traditional Infrastructure-as-a-Service model. With the pay-per-use charging model and no infrastructure to manage, using serverless technology may end up saving you money.

Standardizing your monitoring on a cloud-specific solution like CloudWatch will most likely give you lower costs compared to implementing a cross-cloud solution. Using managed service solutions may also allow you to reduce your people costs.

Another benefit from standardizing on one cloud is simpler training for your staff. And finally, consolidating all your workloads may entitle you to a volume discount from your cloud service provider.

Conclusion

While avoiding technology lock-in is undoubtedly a good principle to uphold, you should consider all IT principles holistically. There are cases where committing to a single technology or cloud vendor makes sense. Perhaps you are just starting your journey and would like to “dip your toes” in the cloud so you can quickly learn the technology. Maybe you are an SME business with limited IT resources, and willing to accept lock-in for letting the cloud service provider handle all your infrastructure operations. Or perhaps you are under an aggressive schedule and need to build and launch your product quickly.

As with all business decisions, you must understand the benefits to be gained from the costs you pay. Technology lock-in can be acceptable if the benefits are justified. If you decide to accept the risks from technology lock-in, be sure to review them again in the future and assess whether they are still acceptable to your business. Technology lock-ins should be considered as “IT architecture debts”. Debts must eventually be paid, but you need to find the right time to do it.

#itsecurity #cloud

According to the 2018 Cloud Computing Survey by IDC, nine out of ten companies will have some parts of their application or infrastructure in the cloud by 2019. Migration to the cloud is very much the norm in IT today and cloud budget continues to increase year after year. The IDC survey points out that the top two reasons for going to the cloud are “improving the speed of IT service delivery” and “greater flexibility to react to changing market conditions.” In other words, business agility is the top reason for cloud transformation.

At the same time, speed and agility are often at odds with IT security policies. The same IDC survey highlights that “security concerns” is the second leading barrier for cloud adoption. Moreover, cybersecurity is usually at the top of CIO’s agenda and investment priorities in 2019.How do we reconcile agility and cybersecurity protection in the cloud?

While at first glance the two seem to be clashing, it is possible to have both speed and security in the cloud. In my observation, the inefficiencies that prevent speed in the cloud are often caused by a lack of understanding of the “shared responsibility” model and by legacy processes written for on-premise data centres.

What is the “shared responsibility” model?

Cloud service providers (CSP) have evolved so much beyond mere providers of storage and server capacity. Today, most CSPs offer hundreds of services, which can be categorized as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). You can think of these different categories as how much you want to outsource to the CSP.

As with all outsourcing arrangements, engaging with a CSP requires clarity of roles and responsibilities. The “shared responsibility” model must be understood so there is no duplication of work between you and the CSP, and accountability on security oversight is clear.

As you move from IaaS to PaaS and SaaS, you will be responsible for less, and the CSP will take responsibility and accountability for more. Please refer to the table below (note: non-exhaustive).

Your ability to outsource more responsibilities to the CSP will depend on how much you can trust them. It is critical, therefore, to establish this trust before the cloud engagement begins, then continue to hold CSP accountable. Many mature organisations perform a standardised onboarding process for their vendors, including auditing the CSP against the organisation’s security policies.

Holding CSP continuously accountable can be done through agreed performance expectations (e.g. metrics and KPI) and periodic management oversight meetings (e.g. monthly). Some mature organisations also require their Vendor Management team to perform annual evaluations on the CSP. Besides ensuring the CSP stays vigilant, annual vendor evaluation will also ensure the cloud arrangement stays aligned to your ever-changing business strategy.

Updating legacy processes for the cloud

Another frequent hurdle in cloud agility is legacy processes which were written in the context of on-premise data center. Often, implementation of these processes does not take into account that faster executions are now possible through automation “as a service” on the cloud.

Here’s one example: Many organisations have a policy that servers, networks, and environments must be configured according to security standards. Compliance to this policy is often the responsibility of the security team that would perform scanning on all servers, networks, and environments. This scanning activity is often done manually and therefore only done at monthly or quarterly intervals.

Most CSPs now provide the ability to “codify” your security standards so you can perform automated scanning in real-time against them. Instead of compliance review every month or quarter, you can now be continuously compliant. Moreover, this scanning capability is provided “as a service” and therefore quick to implement and very affordable. In fact, the hurdle to implement this in many organisations is usually ignorance that such service even exists. Major CSPs invest billions of dollars in R&D and they introduce new features every week. Thus, your cloud journey must include monitoring and continuous assessment of these new offerings.

As different organisations are at different maturity stages in their cloud journey, my recommendation is to adopt a “continuous improvement” approach in updating your legacy policies and processes. Figure out where bottlenecks occur and where there are most security risks, then prioritise accordingly. Of course, in line with the security tools and process change, you should also train your staff with the skills required to effectively utilise the services available in the cloud.

In this article, I have only touched the security aspect of a cloud adoption journey. It is important to establish your security non-negotiable standards early in your cloud journey, so you can move on to other equally important areas such as business alignment, culture, and governance. Good luck!

#itsecurity #cloud