Background – European Cloud Providers
In this series’s first part, we took a high-level view of what services European Cloud Providers have to offer. In these upcoming parts, we will focus on one Cloud Provider each, with a more in-depth, as well as technical view. We want to evaluate the feature-richness of the different offerings, as well as their usability from a DevOps Engineers / Solutions Architects point of view.
Open Telekom Cloud (OTC)
The Open Telekom Cloud, in further parts called OTC, is a European Cloud provided by the German T-Systems International GmbH and offers a very broad spectrum of services available currently in Germany and the Netherlands.
Developer Experience
There are multiple ways, how a developer can interact with the OTC. We will take a look at three different approaches used during the evaluation.
OTC Web Console
The OTC Web Console is my main entry point to the OTC, when you want to get an overview of the different service offerings and what features a service has to offer. It is themed in Telekom Magenta, while delivering a very convenient experience for everyone familiar with Azure or AWS Web Console.
It is great for getting an overview or experimenting with different services. Of course you can also create, edit or delete existing resources here, however and this is not specific to OTC, for real world applications it is advisable to have reproducible architecture and thus we prefer IaC to manage our infrastructure. Nevertheless, the Web Console offers everything you might be looking for as a Developer / Solutions Architect.
A notable mention, because it is rather uncommonly placed, is the Cost / Budget Dashboard, where one can see the resources that have been provisioned and what cost they are incurring. However after some searching one can find the „Consumption Dashboards“ that are not directly integrated in the OTC UI, but rather stand next to it as managed Grafana Dashboard. This fulfills its purpose and shows an overview of the costs down to the service level.
Special Notes to the Pricing Calculator for OTC, which offers a great User Experience and directly shows you a good estimate of the produced cost for your planned solution.
OpenStack CLI using OTCExtensions
OTC is built on top of OpenStack and the OpenStack API is fully exposed. However to make life easier, OTC published an extension pack for the OpenStack CLI, called otcextensions that has predefined OTC resources that you can query or use with your CLI. This is basically their replacement to proprietary CLIs like they are provided by StackIT or Scaleway or even AWS, however this works basically interchangeably, with the small benefit, that those familiar with the OpenStack CLI do not have to adapt to something different.
Terraform / OpenTofu Provider
The Terraform Provider was the main point of interaction with the OTC for creating, updating and deleting resources. And there is not much to say about this one. It just works!
Working in combination between the OpenStack CLI and the UI to find potential defaults and identifiers, like instance class names, it is very easy to setup a running infrastructure with the given provider. The provider is maintained as an open-source project directly by the OTC-Team.
There is also the possibility to use the OpenStack Provider for Terraform, however therefore you need to be really familiar with the OpenStack architecture and their components. The official Terraform Provider is that good, that I would always prefer it to the OpenStack provider, since your changes directly reflect in the UI and it’s much easier to trace them.
Technical Documentation
The OTC offers a rich Service Documentation, which gives details on the service level as well for the Web Console, as well as the API. Additionally there are official Architecture Best-Practices one can follow during usage of the OTC.
These resources were sparsely used during evaluation. The Terraform Provider has great documentation and delivers information on the possible parameters. Additional required information was easily gathered with the Web Console and the OpenStack CLI. There were no major problems finding relevant information and everything could be setup as expected. Technical Documentation is good for getting started with OTC and also very detailed for experienced users.
Feature and Service Overview
As already seen in Part 1 of this series, the OTC cloud checks most of the boxes for our evaluated Features, only lacking a dedicated CDN and a Managed Messaging Service.
For CDN, this would not make much sense at the current state with regions solely in the Netherlands and Germany, thus not spreading a larger area around the world.
The Managed Messaging is in my point of view a very desirable feature for the future. Using e.g. AWS SQS or even Amazon MQ is much more comfortable, than deploying and managing your own messaging solution and can make development time for future features, because the maintenance effort is much less with managed solutions. The only alternative is the DMS Service, which allows to have messaging by leveraging Apache Kafka, but this is a very large and resource-intensive solution for many use-cases that just want to decouple using Queues.
For the other Services the focus lies on the following:
Project and Account Structure
The management structure for the OTC starts with an enterprise account at the root level and then you have different tenants or projects under the root. These can be used for different projects. Within the tenants, different IAM concepts can be used to further structure components.
There is also a universal tagging concept, that can be used to structure components.
Currently there is no concept like Service Control Policies in AWS, that allow you to restrict the services or components a tenant can use. This needs to be handled using IAM permissions or Resource Quotas.
Network
Networks in OTC are organized in a familiar structure of Region-spanning VPCs, which are sub-divided in VPC subnets which always belong to one AZ.
By default, every subnet is considered private. This means, the resources cannot be reached from the outside (they are not internet-routable), however, they also cannot reach the internet.
In order to get internet access for components within the subnet, one needs to create a NAT Gateway with a Public Floating IP and associate the subnet’s routing table with this NAT Gateway.
If you want a component to be reachable from the outside, there is no need to make a whole subnet public, like it is in AWS. You rather only associate a Floating IP with that component and then it is reachable via that IP. Floating IPs are fixed.
In General, every component that wants to directly interact with the internet, like e.g. Kubernetes Control Plane, NAT Gateway or Load Balancers need to be assigned a floating IP, which is then charged.
The network security concept is well known from other cloud providers. While different instances get associated Security Groups, which are stateful and regulate the inbound and outbound traffic at the instance level. There are also Firewalls, which are the equivalent of what other providers call Network ACLs, so stateless network restrictions on the subnet level.
The networking concept feels very similar to what we know from AWS, with some small differences. It enables the required security aspects of separating concerns and separating public from private components, while not providing too much overhead.
In order to connect different VPCs, there is the concept of VPC peering that works within an account, as well as cross account. For star-shaped connections between multiple VPCs you can use the Enterprise Router component.
If you want to connect your corporate data center to the OTC, there is the possibility to setup a managed S2S VPN or to establish a physical data center connection. Both allow access to private resources and just like AWS, with the use of VPC endpoints you can get access to services like OBS (S3 Storage) privately with your direct connection.
Finally a nice addition, that shows within the details. Access to OTC Services, like OBS (S3 Storage) always pass through the OTC network, not relying on VPC Endpoints (which are solely for Corporate Data Center Connections), which results in no outbound traffic cost, when transferring the data to your instances.
Identity and Access Management – IAM
The IAM shows a familiar concept of Users, Groups and Permissions.
A user can be assigned to an arbitrary number of groups and gets the permissions assigned to that group. For programmatic access, it is possible to generate ACCESS_KEY and SECRET_ACCESS_KEY.
Policies allow fine-grained permissions on different services. However currently the restriction to specific target resources is only possible for a specific subset of services, like OBS. It is e.g. not possible to grant a user full access to one RDS instance and only read only access to another instance.
For services and cross-project (cross-account) access, there is the concept of Agencies, which strongly resembles the capabilities of AWS IAM Roles.
For integration of Identity Providers, one can choose between SAML and OpenID Connect.
Cloud Container Engine (CCE) – Managed Kubernetes
Managed Kubernetes instances are setup easily using the CCE service. By default, the cluster including its control plane nodes is only available OTC-internally. In order to reach the control plane from the internet, a floating ip must be assigned.
CCE Clusters come in two manners, HA-enabled and HA-disabled. While the HA-disabled are generally not applicable for production workloads, they are free of charge and therefore offer a great solution for development environments. For HA clusters, one has to pay by the number of nodes that will be part of the cluster ranging from 50 to 2000 possible nodes.
Different node pools can be assigned to the cluster, each being in a single subnet and thus in a single AZ. Multi-AZ environments can, as usual, be created by adding multiple node pools to the cluster. Every node pool has a fixed instance size and operating system and they support auto scaling.
Elastic Load Balancer (for Kubernetes)
The OTC offers Elastic Load Balancers in two flavors. Shared Load Balancers operate on shared virtual hardware, while for dedicated load balancers you get guaranteed hardware and throughput as well as a guaranteed number of availability zones (1 – 3).
Every load balancer is assigned a single region and is by default an internal load balancer, which can be made public using a floating IP. This is different to HTTP load balancers of other cloud providers, e.g. AWS, where they only get a fixed DNS Name, not a fixed IP address.
The load balancer was specifically tested in combination with the Kubernetes cluster to serve as the ingress controller. In the OTC, the Load Balancer must already exist, when you want to attach it via a Service of Type LoadBalancer to the Kubernetes Cluster. This is probably personal preference, but in my opinion this is a good thing. For one, your load balancer and your floating ip are not destroyed, when you remove the ingress controller from you cluster and two, all your infrastructure definition lives in you IaC scripts and not parts of it are in your application code.
You can either use the CCE Add-Ons to install nginx with the Load Balancer directly attached or you install it directly yourself, e.g. via Helm and link the Load Balancer accordingly.
Object Storage Service (OBS)
For S3-Compatible Storage in OTC, there is OBS. This service allows you to create and manage Buckets in the OTC.
Buckets thereby have a wide variety of features.
You can select between three storage classes, Standard being the default, Warm which is a warm archive for long-time but still accessed storage and finally there is cold for long time archiving.
There is the possibility to create a standard private bucket, a public read bucket or a public read and write bucket.
For public buckets, it is possible to enable static website hosting.
Additional Features include Server-Side Encryption (with KMS or Default Key), Versioning, Access Logging, Requestor Pays, as well as a WORM (Write Once Read Many) model for auditing purposes.
For data management, there are lifecycle rules to transition between different storage classes and also automatic Cross-Region Replication.
Permissions are handled as a combination of IAM, Bucket ACLs and Bucket Policies.
If you need to react to operations in a specific bucket there is either the possibility to grep the logs or to used predefined Event Notifications that send to SMN, which is OTC Notification Service similar to AWS SNS.
Databases
The OTC offers different types of databases including SQL, NoSQL Databases and Caching Solutions. This chapter focuses on Relations Database Service (RDS) for PostgreSQL and Document Database Service (DDS) for MongoDB.
For all databases the disk can be encrypted natively and for network isolation the database is by default only accessible from within the subnet. Additionally security groups are regulating inbound and outbound network traffic. In-Transit Encryption using SSL is also possible with an OTC-provided certificate.
RDS offers the possibility to have managed database instances for PostgreSQL, MySQL and Microsoft SQL with recent versions. All these instances can either be created as a single instance for development or non-critical workloads or in a HA Primary / Standby fashion. Additionally you can provision Read Replicas, which serve readonly traffic for very read-intensive applications.
Backups for RDS can be created as full backups or incremental backups and there is also PITR (Point in Time Recovery). One inconvenience here might be that always the whole DB instance needs to be restored not single logical databases.
DDS offers MongoDB managed instances in Cluster, Replica Set or Single Node configuration.
Backups for DDS are also created on a per instance level and there is currently no PITR available.
Container Registry
Container Images can be stored in Software Repository for Container (SWR), which is private OCI compliant container registry.
For Vulnerability Scanning, Host Security Service with its components Asset Management and Container can be used, where you can scan your uploaded and also deployed images for vulnerabilities.
Conclusion
OTC offers a wide variety of services, which are very matured with a very broad feature set. The deployed test architectures worked without any issues and it was a pleasant experience working with the OTC.
IaC using OpenTofu works great and the combination of OpenStack CLI and OTC Web Console give a great overview of what was deployed and what could be deployed.
While it is a bit unfortunate that OTC is missing a managed messaging service and that there is no SCP-like concept, the other services convince for a very matured and pleasant state and experience.
You will be able to bring basically every cloud-ready project out there to the OTC and be able to run a great product out of that, with a lot of support from a feature-rich Cloud Platform.
