Skip to main content

Provide Resources as a Service (Cloud)

Context​

Microservices are adopted. Microservices have infrastructure services or other microservices as dependencies. There is no sophisticated deployment environment yet. Potentially, there is a single-node deployment.

Problem​

  • The resource need of microservices changes dynamically based on the load of the system
    • Resources for microservices are not available when needed

Solution​

Deploy the microservices to a cloud environment that dynamically provisions resources such as computing power, storage, and network bandwidth on demand.

Microservices are a natural fit for the cloud as their individual scalability is especially resource-efficient. Using containers as deployment artifacts allows the portability to various environments, including cloud platforms.

Deployment targets can be private (self-hosted) or public cloud instances (as Google Cloud, AWS, Azure, ...), as well as combinations called hybrid (private + public combined) or federated cloud instances (multiple public ones) to optimize for costs.

Clouds can offer different types of services

  • MaaS: on-demand infrastructure instances/access of bare-metal machines, network, storage;
  • IaaS: on-demand infrastructure instances/access of virtualized machines, network, storage;
  • PaaS: on-demand instances/access of a cloud platform;
  • SaaS: on-demand instances/access of an operated software
  • FaaS: deploying and serving the functionality of a small function. Additional steps as containerizing the piece of software, or scaling the deployed software up and down based down on its load is managed by the cloud platform transparently.

Borders between those categories are fluid and can build on each other to comprise a cloud software. When speaking of "deployment to the cloud" most people speak about PaaS clouds. A cloud platform is a cloud software that provides a suite of tools to deploy, operate, and connect software applications. The infrastructure-level has not to be considered as the platform sits as layer of abstraction above. The platform can offer additional services as managed databases, managed messaging mechanisms, ecetera.

If you want to deploy to a cloud without binding to vendor-specific functionality leading to a cloud vendor lock-in, please consider deploying to a cluster manager instead.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L5:

  • PaaS and container orchestration tools provide various features to make deployment and operation trivial
  • selecting the right platform becomes trivial
  • each platform comes with its assumptions => follow them to use their potential

L7:

  • Context: Interesting practitioner questions
  • deploy to public or private cloud offerings? or to more traditional application hosting environments?

L8:

  • Microservices usually deployed to cloud using containers

L14:

  • Scalable systems should react to changing workloads automatically with elastic capacity management
    • offered by cloud infrastructure

L21:

  • Easy scaling makes microservices natural technology for cloud
    • popularity will probably continue when more apps moved to cloud
  • open problem is how microservice may integrate with main emerging platforms
    • cloud: seems to be ideal thanks to portability and elasticity of microservices
    • IoT: still presents some difficulties

L23:

  • more and more cloud providers; smaller/medium ones cannot compete with larger ones
  • smaller and medium clouds can establish stronger partnerships to share resources according the rules of the cloud federation systems they belong to
    • with large providers => gain economics of scale, optimize their assets, scale capabilities, share resources to establish new forms of collaboration
    • if small provider's cloud runs out of capacity => migrate its microservices to federated data centers to ensure business continuity
  • federated clouds
    • need to respond to high heterogeneity across independent cloud systems
    • make data exchange among clouds efficient and secure
    • efficiently deploy resources and services across federated systems
    • => microservices and containers best solution to quickly adapt to changes in the federated system #

L24:

  • microservices can ideally packaged, provisioned and orchestrated through the cloud with the usage of lightweight container technology

L28:

  • Microservices involve developer building a web service as container image on their laptop and then transfers the image to a production cloud
  • Cloud vendors cannot escape from hosting large numbers of microservices

L34:

  • Context: categorization of research challenges
  • Deployment operations: focus on deployment efforts, automation, resource utilization with respect to efficient scaling
    • related to containers
    • related to cloud-based infrastructure
  • Symbiosis with IoT, cloud computing, PaaS and Big Data => all can be addressed using microservices, but beyond the paper

L35:

  • Figure illustrates typical microservice-based architecture in a cloud platform
  • Examples for cloud platforms: AWS, IBM Bluemix, Azure
  • Application leverages services by cloud patform
    • managed databases, message queues, data analytics

L40:

  • Microservices use APIs provided by IaaS layer for provisioning data computing, storage, delivery capabilities
  • Growing adoption of microservices in the cloud
    • ease of deployment and updating the software
    • provisioning loosely coupling by dynamic service discovery and binding
    • decomposition allows to offer high scalability guarantees by efficient consumption of cloud resources
    • dynamically and quickly restructure software to accommodate growing consumer demand
  • Security as a service for microservice-based cloud application might be an attractive solution

L41:

  • Context: migration case
  • until now: VMs ordered through web portal and manually set up
  • roadmap: use Red Hat Openshift as IaaS/PaaS platform for internal data centers

L49:

  • support for deployment can be provided by a PaaS cloud platform
    • scale system automatically
    • manage it
    • provide middleware for message communication
    • monitoring mechanism to control flow of microservice app
    • => by specialized PaaS solution or integrated in existing PaaS

L53:

  • traditionally microservices located in the cloud
  • IoT: additionally associated with device, edge cloud or gateway component, or deployed in larger internet cloud
    • edge cloud and fo cloud extend traditional cloud computing paradigm to the rim of IoT
      • virtualized platform serving as on-demand execution environment of microservices close to the devices or the data source
      • different from running the microservice on the device itself
      • can provide better architectural flexibility, e.g. offload microservice to edge/fog cloud from device to meet changing requirements of service performance
    • => better performance due to locality and the data stream management

L54:

  • Comparison of different architectures
  • Mostly cloud based: microservices
    • not: client/server, mobile agents, SOA

L59:

  • microservices fit particularly well with cloud computing
    • enables economic benefits of microservices to complement economic benefits of cloud computing
    • cost and user experience optimization
    • rapid release of microservices works well with cloud-based online systems that don'T require further distribution of software updates
  • Cloud = mass of microservices
    • understanding of microservices opens door to participating in this huge new market and to exploit the benefits to achieve competitive advantage
  • instead of spending much money to build out compute, storage, and network infrastructure: pay for microservices
    • for each invocation (obvious cost)
    • data transferred to and from a cloud (potentially hidden cost)
    • buy for maintenance and update of other services (compute, storage, complete SaaS functions) instead of doing it yourself

L61:

  • Microservice architectures particularly suitable for cloud infrastructure
    • greatly benefit from cloud-enabled elasticity and rapid provisioning of resources

L63:

  • Cloud computing is able to fulfill requirements
    • ability to suply a variable amount of resources: computational power, storage, network capacity
    • => dynamically scale up and down
    • intelligent utilization is not trivial
    • many migrated legacy apps only use static set of resources
  • Need to utilize dynamic and scalable nature of IaaS to support large number of applications
    • advanced tools to support devs
  • custom developing cloud awareness not feasible for SMEs as significant training and development efforts
  • Cloud computing is natural platform for microservices
    • enables execution and resource allocation of indep components based on their specific needs
    • one microservice might require a lot of storage while another is CPU intensive
    • monolith: size large enough to be sufficient for worst-case requirements scenario => scenario not present most of the times => wasted resources
  • Cloud instance layer
    • contains cloud instances provided by IaaS cloud prviders
    • can run containers that execute actual microservices
    • represents state-of-the-art cloud technology as provided by various cloud providers

LN41:

  • When microservices deployed to cloud environment, introduce data security issues that private infos of cloud users might be affected or misused
  • Cloud offers advantages, but users are tempted to hold back until such risks are better understood
  • 74% of IT executives and CIOs: top challenge preventing adoption of cloud services model
    • risk of intercepted information
    • competitors might infer business operations from message flow
    • need to look into tamper-proof issues of data sources, authenticity detection, protection of transmitted data

LN44:

  • Context: hierarchical decomp. of security issues of microservices
  • Cloud layer
    • thread example: unlimited control of cloud provider over everything it runs, few technical options to prevent disruption or attacks from malicious provider
    • mitigation examples: reverse sandboxes
  • cloud ventod is a threat
  • other tenants also potential threats using side-channel attacks
  • CA service and reverse STS are security critical => should be run in hardened environment

LM43:

  • Context: SLR findings about microservices in DevOps
  • S03 proposes HARNESS approach
    • provides cloud-based platform for bringing commodity and specialized resources together
  • S16 proposes Neo-Metrobolis: tools for scalability and elasticity of MSA based systems across different cloud platforms
  • Many other factors need to be considered when implementing MSA
    • among others, the cloud platform
    • examples: AWS, Google Cloud Engine, Azure

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • Table 2: many public and private clouds besides on-premise
    • AWS 6x, Google 2x, OpenShift 2x
  • C4-S7
    • operations handled by customer using a multi-cloud strategy
  • C10-S14
    • employ various AWS offerings to host services
      • ElasticBeanstalk, Fargate, Lambda functions as examples
  • Two participants positive about CloudFoundry: more developer friendly than Kubernetes
    • Kubernetes powerful but complex
    • interpretation: CloudFoundry is a self-hosted PaaS cloud platform

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • their system hosted on private data center, so no cloud
    • new hosts cannot be provisioned and de-provisioned as in cloud
    • => want to provide private cloud, work in progress
    • adoption of Red Hat OpenShift IaaS/PaaS platform
    • but currently: web portal, VMs manually by FX Core team

Interview A:

  • introduced Kubernetes => completely new technologies
  • alternative: go to Google Cloud or AWS
    • not a viable option as they are from the public sector
    • had to go to on-premise
    • focus on IT security and data privacy
  • Interpretation: built there own on-premise cloud using Kubernetes as platform

Interview D:

  • Need for completely virtualized environment
    • if we don't get that, we can forget about the rest
    • microservices don't make sense if no on-demand resources available
  • Either use public cloud
    • or virtualize whole computing, storage, network infrastructure + self-service via API

Interview F:

  • communication technology of microservices also depends on what is available on the deployment platform
  • need to care about from the beginning which platform to use
  • integration is hard to do platform independent
  • doesn't matter if Amazon, Microsoft, or something with Docker => but it has a large influence on integration