Martin Dvorak – Page 4 – Martin Dvorak Consulting

Rising Cloud Technologies: API-Centric SaaS, Cloudlets and Blockchain PaaS

New technologies help companies to transform organizations into digital organizations. Identifying the emerging cloud technologies and understanding their impact on the existing cloud landscape can help companies to become more successful.

While some companies do not have a formal cloud strategy in place, most companies are using at least a cloud technology such as SaaS, IaaS or PaaS – whether in a private, public or hybrid cloud.

Other companies follow a multi cloud strategy since it allows them to select different cloud services from different providers because some are better for certain tasks than others. For example, some cloud platforms specialize in large data transfers or have integrated machine learning capabilities.

Most popular cloud models are the hybrid and multi cloud as of today. Seeing the first benefits of cost savings and increased efficiencies, companies focus now more on agility, speed and time to market to enable digital business success.

The new cloud capabilities increase the deployment options. Companies want the benefits of the cloud in all of their IT systems with the increased offering of cloud service providers, customers can now decide on the technology, services, providers, locations, form factors and control.

Since the digitalization journey raises new considerations and expectations, companies are now looking into technical areas to improve their cloud landscape such as the distributed cloud, API-Centric SaaS, Cloudlets, Blockchain PaaS, Cloud Native, Site Reliability Engineering, Containers, Edge Computing and Service Mesh.

API-Centric SaaS

An API-centric application is a web service that is built using application programming interfaces (APIs) to exchange data with other applications and allows the frontend and backend to communicate. In order to prevent these API-Centric SaaS services from coexisting in silo form, they must be integrated, i.e. enabled to exchange data with each other. The transfer of data is structured according to a previously precisely defined syntax. The backend of the app is used to facilitate data exchange with components such as operating systems, databases and other APIs. It is saved on a server that can be configured to a variety of client frontend interfaces like social media channels, browsers and devices. Each API performs a defined task such as merging data from a process or transferring data according to certain rules.

Most API-based SaaS products have no user interface, like a GUI. The interaction with the service is through a web-based API – a programmatic way of connecting services and transferring data across the web in a machine-readable way. The value of the service is usually in the data that’s delivered (through the API). Pricing is often usage-based, meaning that the cost is based on the number of requests made to the API.

The reason to use API-Centric SaaS goes back to the make or buy decision. Instead of spending development time and costs on cloud integration, API-centric SaaS vendors focus on best practice solutions for specific businesses.

For example vendors like Clearbit focus on contextual data such as BI API’s, Contentful on CMS, Twilio for messaging voice, video and authentication API’s for every application, Algolia for high-performance search in the applications used, Checkout for payments and Polygon with market data and their API’s for the FinTech industry.

API’s from specialized vendors as mentioned above can avoid companies to reinvent the wheel resulting in using best practice, flexibility, low code maintenance and code continuity.

API-centric development and integration will become more important for DevOps model application configuration and will drive the deployment process.

However, each interface increases the potential to be attacked, therefore security is a key aspect of APIs. After all, companies use these same APIs to connect services and transfer data.

Companies can no longer afford to view APIs as an extension and evolution of integration-based architectures and, instead, need API management and integration platforms to connect data and applications across multi-cloud and hybrid environments.

Cloudlets

A cloudlet is a mobility-enhanced small-scale cloud datacenter that is located at the edge of the internet. Cloudlet simplifies the efficient delivery and acceleration of personalized applications without the hassle of integrating with the various acceleration services. The cloudlet represents the middle tier of a 3-tier hierarchy: mobile device – cloudlet – cloud and can be viewed as a data center in a box whose goal is to bring the cloud closer.

The main benefit is the short end-to-end communication delay for mobile devices in the proximity of a cloudlet. The cloudlet reduces the latency in reaching the cloud servers and also resides near the mobile devices such as wearable devices, tablets and smartphones within a given geographical proximity.

Blockchain PaaS

Blockchain-as-a-Service, or BaaS, is a managed blockchain platform allowing companies to build blockchain applications and digital services on a distributed network while the cloud service provider supplies infrastructure and blockchain building tools such as set up of a fully functional blockchain environment including not only the ledger itself, but also the infrastructure, user interface, off-chain storage and a complete set of tools for management throughout the software lifecycle.

Does it make sense for companies to invest in their own hardware and software resources for blockchain projects? Especially since the majority of these projects are for individual business areas rather than as a company-wide solution means that business units have rarely sought the support of large IT providers to date, but instead opt for smaller, specialized blockchain technology providers.

For a company to set up its own blockchain environment in the cloud, special know-how is required. Since this knowledge is also not scalable, an as-a-service offer makes more sense for companies than investing in their own resources.

Since blockchain projects are rather short term, it is not reasonable to spend almost the same amount of time on setting up the blockchain. In a short project context, it also makes sense to shift from CAPEX costs to OPEX budgets.

Another benefit is that those business units who initiate blockchain projects usually do not know which tools they will need in the end. These costs are therefore difficult to forecast. In the cloud, users have a whole range of tools at their disposal and they only pay for the duration of tool use.

Also, in all areas in which a large and comprehensive data exchange takes place, blockchain technology can be an answer to mapping this in an audit-proof manner.

Regarding security concerns, a blockchain is secure because it does not need a central instance, for example an intermediary. Each computer in the chain collects the same data. If a user transfers data to another computer, this is done directly from computer to computer. This is entered anonymously in a table and stored in parallel on all network computers. There is therefore no computer that has more information than the others. Malicious manipulations at one location are therefore not decisive or not possible. A wrong date alone cannot falsify the whole system.

Rising Cloud Technologies: Distributed Cloud

While some companies do not have a formal cloud strategy in place, most companies are using at least a cloud technology such as SaaS, IaaS or PaaS – whether in a private, public or hybrid cloud.

Distributed Cloud

While the cloud does not restrict locations, the most common cloud configuration is centralized. Companies respond to the evolving cloud technologies and business models.

The hybrid, multi cloud and edge environments are increasing and they set the stage for the distributed cloud.

The distributed cloud interconnects data and applications served from multiple geographic locations and shared among multiple systems in different locations. A decentralized cloud services offering has less distance between the service source and the service user. It brings resources closer to the use of services. This reduces the latency of data transmission and increases the performance of services and better redundancy.

The distributed cloud is based on centralized and decentralized services and ensures optimal use of network access and available transport bandwidth. The services can be accessed at different locations.

Distributed clouds can be structured in different ways. Hierarchical cloud concepts are often used for implementation. In this case services are provided via different cloud hierarchies such as a central cloud, multiple regional clouds and many edge clouds.

The central cloud provides all services and receives or sends data from regional clouds or edge clouds. Regional clouds perform proxy and caching functions and act as intermediaries between the core cloud and the edge cloud or offer services themselves. Edge clouds are placed as close as possible to the user and provide cloud services with minimal latency.

Caching plays an important role for a distributed cloud. Intelligent caching mechanisms are necessary to avoid having to reload data from a central core cloud for each request, but to keep the information close to the user. Caching is not just about caching data, but in some cases complete services. Caching must ensure that the frequently required data and services are actually stored directly in the edge area. In addition, the cached data in a hierarchical structure must constantly synchronize with regional and central cloud services to avoid inconsistencies.

Challenges

The challenge of a distributed cloud is caused by the usage of many different individual components and services. This creates a heterogeneous environment that must be well managed. The distributed cloud must ensure compatibility between services, networks and individual components. The heterogeneity can occur in heterogeneous hardware platforms, infrastructures, network technologies, connections, devices, software implementations and service providers.

Advantages

Cloud providers use the distributed cloud model to bring their cloud services to the user with higher performance, better availability and lower latency. By using a distributed architecture, services can also scale better and adapt to user needs. Both the performance of the network and the service itself are well scalable. The fact that less data needs to be sent to a central cloud dramatically reduces central bandwidth requirements. Bottlenecks and congestion can be avoided. This is especially true for applications with high bandwidth requirements such as video streaming.

Compliance

Regulatory or compliance requirements are in favor of using a distributed cloud. Cloud services can be provided geographically distributed according to different country specific or regional legal requirements such as coming from the European Union. The availability of services increases because distributed cloud structures continue to function for a certain time regardless of the availability of the core cloud. Applications such as autonomous driving or automated industry 4.0 processes benefit from this, as the higher availability ensures greater security or avoids production downtimes. Further advantages include transparency to the user and working independently of the user’s location, mobile use and real-time applications due to its low latency.

Examples of possible uses

The distributed cloud is suitable for a wide range of applications. A typical application is content delivery networks. Decentralization ensures that content such as video is delivered in high quality regardless of the user’s location. Content delivery solutions work across different network technologies and use decentralized storage systems with intelligent caching technologies. They provide high bandwidth for users and reduce the centrally required network capacities. Instead of delivering and transmitting each video stream several times from the source to the recipient, the image material is stored decentral and only sent from there to the recipients.

Another example of application is the processing and storage of personal data. There are legal or regulatory requirements that prohibit the processing of personal or other sensitive data outside of a certain country or region or only allow it under strict conditions. A distributed cloud can be used to keep all affected data within the desired region.

Conclusion

The distributed cloud brings together Edge Computing, hybrid cloud and new business cases for cloud computing. It represents the future of the cloud and focuses on the topic of location.

Companies realized the benefits of the distributed cloud and move services to the locations where they are needed while operation, governance and evolution of the services remain in the responsibility of the public cloud service provider.

Most companies will use a distributed cloud option which is multi cloud and portability focused, such as portable applications and services. Another major part of companies will use a distributed cloud option and are not yet sure about their preferences.

Other plans are distributed clouds in an ecosystem approach which are led by a single vendor or leverage an edge computing approach not driven by a centralized vendor approach.

One out of ten companies are not interested in a distributed cloud option.

In future, companies can go to a cloud service provider and request resources to manage a workload that needs to meet certain compliance (i.e. GDPR) and business requirements (i.e. use of resources such as Internet of Things (IoT), assets, smart buildings using sensors to interconnect).

Executing the cloud strategy: destination or destiny?

Moving from the strategy to the execution is mapping your cloud design specifications to the cloud adoption framework. For every company, a cloud strategy may look different such as:

The cloud strategy is mostly focused on adoption, migration and implementation.
The cloud strategy is more a data center strategy.
The cloud strategy is different from adoption, migration and implementation.
No formal cloud strategy in place.

Most companies struggle with where to start with a cloud implementation and how to keep the process moving. It is mission critical to secure a mandate from the top executives. Translating the cloud strategy is more than a technology change. It is a transformation on how the business operates. If a company has a decentralized approach, there is a risk that there is not enough simplifying and eliminating complexity and they will not be able to quickly take advantage of new technologies and tools when they become available. Global Process Owners (GPO’s) should be empowered to make decisions.

Companies that have heavily customized their applications will see a lot of benefit from standardizing and simplifying their business processes, which they can do either before (fix and shift), during or not during their move to the cloud (lift and shift). Multinational companies which standardized their processes have an easier cloud strategy execution as they reduce complexity, increases scalability, and make onboarding of acquired companies or demergers easier.

The focus on end users must not be underestimated. While the cloud promises new features and modern technologies, there is no guarantee that users perceive them as a benefit but perceive them as too complex and will not use the new SaaS features. It is easier to address issues in cloud systems as it takes less time to update compared to on premises applications.

By now, you should know which workloads will move to the cloud. The mapping exercise will help you translating the cloud strategy into actions.

Cloud Design Specifications	Translate	Cloud Adoption Framework
Executive Summary	►	Skills and applications, vendor selection, architecture, cloud services and risk mitigations. Costs, estimations, policies and procedures. Provision and automated cloud services. Operating cloud environments at scale.
Cloud Generic Baseline	►	Cloud vendor selection per cloud layer. Conduct cloud layer evaluation workshops with different vendors and concrete showcases to demonstrate for IaaS, PaaS and SaaS.
Business Baseline & Financial Baseline	►	Estimate the costs and benefits based on future SLA’s with the vendors, define policies and procedures to have a governance in place.
Cloud Services Baseline	►	Before you order the first cloud services create scenarios with the vendors which cloud services are automated and how cloud workloads are managed. This is also a part of the SLA’s.
Cloud Principles Baseline	►	As part of the vendor selection process, create different architecture scenarios for the private, public, hybrid and multi cloud solutions following your business goals.
As-Is Analysis	►	Create and manage the inventory of systems and applications to assess readiness for the cloud. Identify your shadow IT, technology adopted by business units independently of the IT department.
Security Baseline	►	For each scenario create risk mitigations, security assessments, business continuity and exit scenarios to avoid vendor lock-ins.
Cloud Pilot Project Baseline	►	After map / gap analysis, design a pilot project which fits a specific business goal and use case to build and deliver a Minimally Viable Product (MVP) that can scale later when first benefits have been reached.
Supporting Functions	►	Build the required skills for IT and business team members to be part of the cloud team.
Exit Baseline	►	Go through a future state when the cloud environments are in the operational mode. How are cloud deployments managed? How are the services consumed monitored and measured? This is also a part of the SLA’s with your vendors.

Conclusions and recommendations

Most companies have a cloud adoption framework or a cloud strategy with a cloud first approach. Others do not follow the cloud first approach but do have a cloud strategy of framework in place. Two out of ten companies do not have a cloud strategy or adoption framework.

Executing a cloud strategy has a profound impact on IT processes and the underlying technical infrastructure. Coming from heterogeneous system landscapes, which are very complex and not transparent, companies need to have the full overview and understanding of their systems before the cloud strategy is executed.

Recommendations:

Follow cloud design specifications to building a cloud strategy.
Establish a strategic cloud excellence panel with key stakeholders from across the enterprise and include business units.
Separate cloud strategy from an implementation plan.
Cloud strategy is not the same as a data center strategy or an implementation, adoption and migration plan.
If you have no formal cloud strategy in place, it is never too late to start.

A cloud strategy might seem that it is about IT architecture such as platforms, tools, applications and technologies. It’s not. Cloud strategies are always interrelated with other aspects such as organizational impact, processes, policies, legal requirements and business goals. Companies should adjust their cloud strategy on those aspects.

Top 10 mistakes and myths for a cloud strategy

It is better not having a formal cloud strategy then building a strategy with misunderstandings. The following mistakes should be avoided when formulating a cloud strategy:

Assuming it is an IT only strategy, not involving business
Not having an exit strategy
Combining a cloud strategy with a cloud adoption, migration and implementation
“It is too late – we are already executing”, redoing everything
We are moving everything to the cloud
It is a data center strategy, it is “all in” or nothing
By executive mandate
We use SAP (or Oracle or Microsoft) so SAP (or Oracle or Microsoft) will be our single vendor for cloud services
Outsource our cloud strategy
Cloud first is our strategy

Companies should look out for the following myths before formulating a cloud strategy:

Cloud is always about cost savings
You have to be cloud to be good
Cloud should be used for everything
“The CEO said so” is our cloud strategy
We need one cloud strategy or vendor
Cloud is always more secure than on premises capabilities
Multi cloud prevents vendor lock-in
Once we have moved to the cloud, we are done
Enterprises are moving back from the public cloud
We have a cloud (implementation, adoption and implementation) strategy

Cloud Design Specifications

Every business unit can benefit from a cloud strategy approach when CIO’s focus efforts that connect the cloud strategy with the business strategy in order to create design specifications, implementation and migration plans.

Design Specification	Translation	Action
Executive Summary	Cloud team organigram, business drivers, challenges, risks and benefits.	Create an overall program plan.
Cloud Generic Baseline	Cloud definitions, service and layer categories, delivery models (private, public, hybrid, multi cloud), cloud adoption best practices. If the required IaaS skills are insufficient and more training is required, the migration to the cloud will be delayed.	Required skills, training and communication plans. Invest in IaaS skills first.
Business Baseline	Desired business outcome, detailed risks and benefits, data center strategy, cloud first strategy, where to consider cloud strategy (wave one, wave two). Cloud best strategy to align cloud to the business strategy.	Potential benefits to desired business outcome mapping. Address and define potential resolutions for challenges and risks. Consider any issues that are unique to the enterprise.
Cloud Services Baseline	On demand and pay per use (when to consume), build operating model, hybrid operating model, how to secure, manage and govern hybrid models, comparison self-provider vs. vendor provider.	Define and verify roles in the cloud. Analyze your pre cloud situation how resources were underutilized and overloaded such as backup time, patching, server downtime, change requests deployment, everything which hold up the day to day business processes as well.
Cloud Migration Strategies Baseline	6R Migration Strategies: Re-host, Re-Platform, Repurchase, Re-architect, Retire and Retain.	Conduct migration strategies workshops using the 6R framework to understand the complexity, effort (time and cost) opportunities to optimize.
Financial Baseline	Pricing models, payment models, chargebacks, CAPEX, OPEX.	Define all options. Decide if a service is operating expenses. Define options for cloud contracts.
Cloud Principles Baseline	Cloud workloads, data strategy, cloud first, SaaS first (buy before build), best of breed (consider security and architecture questions) and cloud best (align cloud to business strategy). Business case for public cloud vs private cloud, hybrid and multi cloud. Enhance existing systems to the cloud (Oracle or SAP on premises -> Oracle or SAP cloud), security, fix and shift, lift and shift as a last resort, vendor evaluations.	IT validation from above Business Baseline provided. Cloud first: anytime you want to buy, build or enhance an application or system, validate against the cloud first principle. Cloud best: instead of business follows IT, align the cloud to the business strategy. Vendor evaluation: if you use Microsoft all over your company, it does not mean you must choose a Microsoft Cloud solution.
As-Is Analysis	Business and technical architecture and infrastructure, system inventory, custom applications characteristics, customizations of existing standard systems (i.e. Oracle EBS, SAP), use or evaluate tools (i.e. Panaya, architecture layers, total cost of ownership tools.	Produce assessment where you are today, i.e. inventory of systems based on cloud principles baseline above.
Security Baseline	Security principles, authentication standards, encrypted data, vulnerabilities in shared servers and system software used by public clouds, sensitive data, change vendor, data breach, loss of data, identity access management, define responsibilities.	Apply the findings from security principles to the security and cloud strategy.
Supporting Functions	Staffing, other strategies (business transformation, transitions, Global Business Services, Procurement simplification, etc.)	Align cloud with other strategies to avoid budget, prioritization and staffing conflicts.
Exit Baseline	Vendor contracts, SLA’s, terms and conditions, data ownership, data backup and restore, vendor lock-in, exit strategy by types of services in the cloud, DevOps issues, architectural impact, support handling. The exit strategy is much more than just what is in the SLA defined and not about an accident during cloud operations. It is about the steps required when getting out of the cloud or changing the provider.	Define what-if scenarios when changing a cloud service provider / vendor. Define KPI’s for when to change a vendor. Business case for transferring data from old to the new provider. Use of containers to avoid lock-in. Validate multi cloud scenarios.

The cloud strategy is dominated by IT architectural and security issues. Companies need to pay attention to identify the roles and responsibilities and consider compliance issues.

For the vendor evaluation, companies need to do due diligence and references from those vendors. For example, if a vendor has a good security rating, you still need to hire security experts or train your IT staff or will those experts be provided from your vendor as a service? Who will do the installations of the new software, is the company or the provider?

If the cloud was a car, most vendors do not want to take responsibility on how to drive the car, they just provide you with the car. The how to drive it responsibility is with you.

As-Is analysis with systems and applications inventory

For each workload which potentially moves to the cloud you establish an inventory information addressing the following questions. Taking enterprise applications, data centers, API’s, gateways and the total environment, you will end up with hundreds of workloads.

Owner of the workload, name, author, version.
Does the workload stay at the company or at the vendor?
Is the workload high value or low cost? Consider size/cost with low, medium and high.
Is the workload critical? Consider with low, medium and high.
Vendor with specific information such as on premises only, next release SaaS only, etc.
Virtualized?
Data and security requirements.
Integration requirements.
Sequential (stability, reliability) or exploratory (agility, flexibility) mode?
Performance criteria.

Is the workload well behaved, overprovisioned or unpredictable?

Well behaved workloads are applications and systems which can be estimated with a high accuracy such as Enterprise Applications, cost effective systems, hardware and data centers.
Overprovisioned workloads are increasing or high volume of demands during the year which require consideration during the as-is analysis and application inventory exercise.
Unpredictable workloads are networks, gateways, firewalls, connections, nodes, API’s, etc.

In addition to the as-is analysis and the application inventory, you need to think about your backlog of enhancements and change requests. Based on you outcome from your as-is analysis you can decide whether the enhancement or change request will be better deployed when the workload moved to the cloud.

Last considerations relate to any strategic decisions and plans which impact your inventory. For example, if the company decided to close data centers within the next 3 years, you can use the as-is analysis and inventory above to determine the appropriate actions and start building your cloud migration plan including new skills required such as Data Center Infrastructure Management (DCIM) tools when moving to a hybrid cloud.

Author: Martin Dvorak

Use keywords for your search

Categories

Archive