Lazy Tab Navigation Concept

How to Implement a Lazy Tab Navigation System in Angular

How to Implement a Lazy Tab Navigation System in Angular

In this blog post you’ll learn why you’d want and how to implement a lazy tab navigation system in Angular.

Why go for a lazy tab navigation system?

We at meshcloud provide a solution to manage cloud access, users and projects across cloud platforms. One of our main goals is to make the interaction with the cloud as easy as possible. Besides that we want to decrease the effort of management workflows to a minimum because cloud management is a complex topic with a lot of items to manage.

But how do we want to achieve this?

It is mostly a user facing topic. Therefore we’ve improved user experience in our Angular SPA (Single Page Application) and decreased the necessary interactions for specific management workflows. It is important to navigate between the sections without lagging or freezing.

It is really easy to say that the improvement of the user experience is the key. But what makes the difference to support user friendly behavior?

We’ve invested a lot of time to find a proper solution. We came up with a lazy tab navigation system is what we need which covers all mentioned challenges.
Lazy Tab Navigation Example

What is a lazy tab navigation system?

As the name suggests, the idea is a tab navigation system in which the content is loaded lazy. This will enable us to implement scalable views with a lot of clearly separated sections. But first to the general tab navigation system.

1. Tab navigation system

The tab navigation system is a central component which coordinates the tab creation and holds the tab state. We’ve decided to handle the tab creation based on the route config. This makes total sense because the routes are uniquely identifiable. This means we can automatically prevent the creation of multiple tabs which correspond to the same section. Besides that we have the possibility to create deep links to specific tab sections. This enables us to reference specific tab sections within other views. In general we’ll determine the tab state based on the activated route.

2. Lazy Loading

The other aspect is the lazy loading. Lazy loading is a central Angular feature. It is a design pattern that loads NgModules as needed. For comparison, there is the option to load NgModules eagerly. With eager loading all NgModules are loaded when accessing the web application. This increases the bundle size and for large applications it is not a best practice due to the load time. Eager loading is for a tab navigation system not an option because we’ve a lot of different sections. And we want to allow multiple sub-sections. This would mean that we load every section content up front. From the performance and UX perspective this is not a good approach.

If we now combine the tab navigation system approach with the lazy loading feature we’ll get a really flexible and scalable pattern. The tab navigation system takes the role of describing the context. It is kind of a container which defines the available routes and manages the tabs. In conjunction with the lazy loading feature, we are able to load the content of the respective tab in a dedicated manner.
Lazy Tab Navigation Concept

What is necessary to implement the lazy tab navigation system?

We’ve got an overview about the lazy tab navigation system from the conceptual perspective. Now we’ll take a look at the technical realization and how we’ve implemented this approach.

We need a shared component which covers all criteria of the tab navigation system. This includes the tab creation based on the router config and tab selection based on the activated route. We call the component RouterOutletNavComponent.

Besides that we’ve defined an interface which describes each tab:

  • displayName
  • routerLink
  • selected

Our interface declares additional properties. For example to show/hide a tab depending on a specific condition and to attach a badge with countable information. But this is not relevant for the general implementation. So we’ll leave it out for now.

We call the tab interface RouterOutletNavTab.

Sure, we didn’t implement the tab creation and tab selection logic within the component. We’ve implemented a service that exposes the functionality. This is a best practice to increase modularity and reusability. The component should only handle the user experience. With a clear separation we’ll also increase the testability of the functionalities. This approach should be followed every time ;)

We call the service RouterOutletNavService.

Now let's combine the RouterOutletNavComponent, RouterOutletNavTab and RouterOutletNavService. ****

@Component({
  selector: 'mst-router-outlet-nav',
  templateUrl: './router-outlet-nav.component.html',
  styleUrls: ['./router-outlet-nav.component.scss']
})
export class RouterOutletNavComponent implements OnInit, OnDestroy {

    @Input()
  public readonly styleClass: RouterOutletNavStyleClass = 'nav-child';

  public tabs: RouterOutletNavTab[];

  private sub: Subscription;

  constructor(
    private readonly router: Router,
    private readonly activatedRoute: ActivatedRoute,
    private readonly routerOutletNavService: RouterOutletNavService
  ) {
    this.tabs = this.routerOutletNavService.initializeTabs(this.activatedRoute);
  }

  ngOnInit() {
    /**
     * Select initial tab and navigate to child route.
     */
    this.setupInitiallySelectedTab()
      .subscribe((routerLink: string) => this.routerOutletNavService.selectTab(routerLink, this.tabs));

    /**
     * We listen to the router events to select the specific tab.
     */
    this.sub = this.router.events
      .pipe(
        filter(x => x instanceof NavigationEnd),
        switchMap((x: NavigationEnd) => {
          /**
           * If the firstChild is available then we don't determine the first child tab.
           */
          if (this.activatedRoute.firstChild) {
            return of(x.urlAfterRedirects);
          }

          /**
           * If child route doesn't exists then we'll determine the child route and select the tab.
           */
          return this.navigateToFirstChildRoute();
        })
      )
      .subscribe({
        next: (routerLink: string) => this.routerOutletNavService.selectTab(routerLink, this.tabs)
      });
  }

  ngOnDestroy(): void {
    this.sub.unsubscribe();
  }

  private setupInitiallySelectedTab(): Observable<string> {
    /**
     * If childs are applied for example in case of redirection then we'll use the existing destination url.
     */
    const currentUrl = this.router.url;
    if (this.activatedRoute.firstChild) {
      return of(currentUrl);
    }
    return this.navigateToFirstChildRoute();
  }

  private navigateToFirstChildRoute(): Observable<string> {
    return this.routerOutletNavService.findFirstChildRoute(this.tabs)
      .pipe(
        take(1),
        /**
         * This side effect is necessary to apply the determined tab route.
         */
        tap((routerLink: string) => {
          const extras = {
            relativeTo: this.activatedRoute,
            replaceUrl: true
          };

          this.router.navigate(['./', routerLink], extras);
        })
      );
  }
}

We want to support not only a tab navigation system. We want to support a lazy tab navigation system. So it is necessary to embed a RouterOutlet into the tab container. For the styling we use Bootstrap as external dependency.

The corresponding HTML file would look like this:

<div [ngClass]="styleClass">
  <ul class="container nav nav-tabs">
    <ng-container *ngFor="let t of tabs">
      <li class="nav-item">
        <a class="nav-link" [class.active]="t.selected" [routerLink]="[t.routerLink]" [id]="t.routerLink">
          {{t.displayName}}
        </a>
      </li>
    </ng-container>
  </ul>

  <div class="tab-content p-4">
    <router-outlet></router-outlet>
  </div>
</div>

It is a valid use case to nest multiple lazy tab navigation systems. But for simplification we allow only one additional layer. Therefore we’ve defined two different css classes ‘nav-root’ and ‘nav-child’ to tell the levels apart.

We call the style class type RouterOutletNavStyleClass.

export type RouterOutletNavStyleClass = 'nav-root' | 'nav-child';

Very well done. We've implemented our shared lazy tab navigation system.

Now we have to feed the tab navigation system with the corresponding data. The information about the router link and if a tab is selected will be determined based on the route config and activated route. It is really important to declare the available routes with the lazy loading approach from Angular.

But how do we get the display name of each tab? Sure, we could use the route path name. But the name is our uniquely identifiable name. It could also be a human unreadable string. From the user perspective, it is not a good approach to use an identifier string as tab display name. Besides that we need a way to determine some data up front. Keep in mind, besides the display name we’ve also a condition and badge information in place. So we need the possibility to attach specific session data to each tab. Therefore we need to declare a resolver which returns a RouterOutletNavSessionData observable.

We call the abstract resolver class RouterOutletNavSessionResolver.

export interface RouterOutletNavTabData {
  displayName: string;
}

export interface RouterOutletNavSessionData {
  [key: string]: RouterOutletNavTabData;
}

export abstract class RouterOutletNavSessionResolver implements Resolve<RouterOutletNavSessionData> {

  abstract resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<RouterOutletNavSessionData>;

}

Now we’ve everything in place to use the lazy tab navigation system within a specific use case.

Lazy tab navigation system in action

At this point it makes sense to apply the lazy tab navigation system to one of our use cases. We’ve mentioned at the beginning that we provide a solution to manage cloud tenants. This includes for example the customer management. Within a customer we can manage projects, users, financials and much more. So it makes total sense to use the lazy tab navigation system with one additional level to make the management as easy as possible.

We’ll only consider the customer root level. The nested levels are out of scope for now. But in general they follow the same approach.

Our top level component would be the CustomerManagementComponent. This component declares the RouterOutletNavComponent within the HTML file and applies the ‘nav-root’ style class.

...
<mst-router-outlet-nav styleClass="nav-root"></mst-router-outlet-nav>
...

Then we’ll add all available routes to the CustomerManagementRoutingModule. Besides that, it's important to add a CustomerManagementNavSessionResolver to determine the session data up front. This provides our basis for the tab creation.

@Injectable({
  providedIn: 'root'
})
export class CustomerManagementNavSessionResolver extends RouterOutletNavSessionResolver {

  resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<RouterOutletNavSessionData> {

    const sessionData = {} as RouterOutletNavSessionData;

    sessionData['projects'] = this.getProjectsNavTabData();
    sessionData['access-control'] = this.getAccessControlNavTabData();
    sessionData['financials'] = this.getFinancialsNavTabData();
    ...

    return of(sessionData);
  }

  private getProjectsNavTabData(): RouterOutletNavTabData {
    return {
      displayName: 'Projects'
    };
  }

  private getAccessControlNavTabData(): RouterOutletNavTabData {
    return {
      displayName: 'Access Control'
    };
  }

  private getFinancialsNavTabData(): RouterOutletNavTabData {
    return {
      displayName: 'Financials'
    };
  }

  ...
}
const routes: Routes = [
  {
    path: '',
    component: CustomerManagementComponent,
    resolve: {
      session: CustomerManagementNavSessionResolver
    },
    children: [
      {
        path: 'projects',
        loadChildren: () => import('./projects').then(m => ...)
      },
      {
        path: 'access-control',
        loadChildren: () => import('./access-control').then(m => ...)
      },
      {
        path: 'financials',
        loadChildren: () => import('./customer-financials').then(m => ...)
      },
      ...
    ]
  }
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class CustomerManagementRoutingModule { }

That's it. No additional steps are necessary. We can easily add tabs and nested lazy tab navigation systems to the CustomerManagementComponent. For example we could think about a settings section or projects overview section. There are no limits to the imagination.

As inspiration our customer management view looks like this:
Lazy Tab Navigation Angular


Google Cloud Checklist

Google Cloud Landing Zone Comparison

Google Cloud Landing Zone Comparison

When researching how to set up your Landing Zone in GCP you come across different options provided by Google. In this blog post, we compare several key aspects of the different solutions. We had a deep look into these solutions and rolled them out in a GCP Test Organization to evaluate how they perform. After reading this blog post you will understand what the different options are, which features they provide, how easy it is to use them and which option fits best to your use-case.

Your Options to Create Google Landing Zones

Google Cloud setup checklist

In the GCP web console, you can easily set up a basic cloud foundation via a wizard called “Set up your Foundation”. It is based on the Cloud setup checklist by Google. It covers the most relevant topics that should be considered for a secure and scalable cloud foundation.

It does not apply most of the configuration directly via the web console but generates Terraform Modules. So the wizard is a nice and handy frontend for configuring some Terraform. You are guided very well through the different things that will be applied and how they are configured.

Google Cloud Checklist

Cloud Foundation Toolkit - Example Foundation

Based on the Cloud Foundation Toolkit, Google provides a Terraform Example Foundation. It can be used as a basis and customized to individual needs. It already applies best practices and reasonable defaults that should fit many companies.

Terraform Modules are structured into different stages (bootstrap, org & resource hierarchy, environments, networking, projects, and app infrastructure). After bootstrapping the basic structure and projects by executing Terraform, it provides the option to roll out the remaining stages via CICD. Google Cloud Build and Jenkins are supported for this. But you still have to prepare the different stages by executing several commands manually before the deployment is triggered via CICD. For execution via CICD, it uses a Google Cloud Git repository per stage.

[cta_box title="Do you need support building your Landing Zone?" text="Book a free expert call here, to learn more about modular Landing Zone Best-Practices." background-color="000000" button_text="Book Free Expert Call →" button_url="https://app.harmonizely.com/meshcloud/livedemo"]

💡 We did not complete rolling out the Example Foundation as we ran into permission issues we couldn’t figure out. As we came to the conclusion that Fabric FAST is the more mature and future-proof approach, we decided not to dig deeper into rolling out the example foundation. Details about this can be found in the next sections.

Cloud Foundation Fabric FAST

Cloud Foundation Fabric is the latest approach by Google to provide a landing zone solution based on the Cloud Foundation Toolkit that is easier to apply, extend and roll out than the Terraform Example Foundation mentioned before. The result of this is the production-ready blueprint for a secure organization called Fabric FAST. It is a set of Terraform modules structured into stages (bootstrap, cicd, resource hierarchy, security, network, project factory, data platform).

Fabric FAST comes from engineers in Google Cloud's Professional Services Organization, with a combined experience of decades solving the typical technical problems faced by GCP customers.

Beyond setting up and configuring a secure Organization and Resource Hierarchy it also provides a Project Factory which enables a GitOps Workflow to provision new projects.

Initially, you need a Super Admin for Google Workspace to set up some groups and assign people to these groups. Afterward, everything is done via Terraform.

Stages of Fabric FAST

Comparing GCP Landing Zone Options

For this comparison, we assign 1 to 3 ⭐ for different aspects that we look at for the three options. If a certain aspect is not covered at all we assign a ❌. Additionally, you can find some details about why we rated an aspect. These details also provide a deeper insight into how these aspects are covered within the options.

GCP Landing Zone Feature Comparison

The feature comparison is based on the Cloud Foundation Maturity Model (CFMM). You can read details of what these blocks mean on the CFMM Website. You can also follow the links in every row that redirect you directly to the details of the according CFMM block.

Checklist Fabric FAST Example Foundation
Resource Hierarchy ⭐⭐ You can pick from 4 different hierarchies, which makes it quite easy to find a hierarchy that matches your needs. Using even more custom ones is also possible by adapting the generated Terraform code in the end. ⭐⭐ A hierarchy that fits many companies is applied by default. It is divided into common branches like networking or security. A “Teams” branch contains all end-user projects. It can be easily customized via input variables (also see Tenant Provisioning below). Applying a completely different structure requires adaption to the Terraform files. For other hierarchy structures, you can also use blueprints provided outside the context of fast stages, see “example foundations”. ⭐ The example foundation only rolls out one specific resource hierarchy, which is separated by environment (dev, non-prod, prod). Using custom hierarchies has to be implemented on your own.
Resource Policies ⭐ 3 basic policies can be applied manually via an optional step in the wizard, they are not part of the generated Terraform code. ⭐⭐⭐ Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand. ⭐⭐⭐ A good amount of reasonable default policies are rolled out via Terraform. They match the best practices provided by GCPs Cloud Foundation Toolkit.
Centralized Audit Logs ⭐⭐ Basic centralized logging is configured by default. You have to follow manual steps to push logs to BigQuery, SIEM, etc. ⭐⭐⭐ By default, it captures logs from GCP’s Cloud Audit and VPC Service Control violations. It can be further customized to capture even more logs by configuring what is so-called log sinks. That way you can i.e. push logs to BigQuery or a SIEM solution. ⭐⭐⭐ Centralized Audit Logs are applied and you can configure exports to BigQuery, pub/sub systems, and more.
Cloud Tenant Tagging ⭐⭐ Tenants can be tagged via the project’s YAML file of the project factory. Defaults that shall be applied to all projects can also be defined. Tags cannot be defined at the Team level yet. ⭐ It sets some default labels like environment, security contact, etc for all projects. But adding any custom tags requires modification of the terraform files.
Tenant Provisioning/Deprovisioning ⭐⭐ With the project factory, GitOps-based tenant provisioning can be applied. As the project configs should better be reviewed by a cloud foundation member, it is not full self-service for the end users. When removing the project definition again, the tenant will be deprovisioned by terraform. ⭐ With stage 4-projects you can define projects, but you have to touch Terraform files to create or change projects. This feels more like coding instead of configuring it as it is done with Fabric FAST. So this approach of modifying Terraform does not seem to result in the best GitOps flow for managing projects.
Playground/Sandbox Environments ⭐⭐ It provides a dedicated folder for Sandbox environments. This folder has different and softer org policies applied. That allows for quicker evaluation as more complex, but secure policies don’t have to be applied here. Sandbox projects can be created via the Project Factory just like normal projects. They are just put into the Sandbox folder. Automatic expiration of Sandbox environments is not part of Fabric FAST. It has to be implemented in the GitOps flow around it. ❌You could consider adding “Sandbox” as an additional environment with some special policies applied, but the example foundation does not provide any guidance for this.
Privileged Access Management (PAM) ⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning only necessary roles for each group. ⭐⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning only necessary roles for each group. Furthermore, service accounts are created for automation that can be impersonated by selected groups. ⭐⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning necessary roles for each group. Furthermore, service accounts are created for automation that can be impersonated by selected groups.
Service Account Management ⭐⭐⭐ With the project factory, project configuration can also include service accounts provisioning alongside their permissions. By default, iam.disableServiceAccountKeyCreation organization policy is enforced on organization-level. This is a best practice that makes use of Workload Identity Federation (WIF) as an alternative to key creation. ⭐ I couldn’t find out for sure, but one service account seems to be created per project. This SA can then be impersonated by the Cloud Build SA to perform CI/CD tasks within the project. By default, iam.disableServiceAccountKeyCreation organization policy is enforced on organization-level. This is a best practice that makes use of Workload Identity Federation (WIF) as an alternative to key creation.
Virtual Networks ⭐ Separate networks per environment are created and some basic firewall rules are applied. That way you can have the connectivity within one environment (e.g. all production services can talk to each other securely via a VPC). Advanced options like configuring peering or VPN approaches are not provided. ⭐⭐⭐ Offers sophisticated virtual network setups based on the “hub and spoke” design. One can choose the type of connectivity between the hub and spokes, which are: VPC Peering, Network Virtual Appliances (NVA), or VPN ⭐⭐⭐ Offers sophisticated virtual network setups. One can choose the type of connectivity between Dual SVPC or Hub & Spoke.
On-Prem Connect ⭐⭐⭐ On-prem VPN is offered with all 3 setups of the networking stages. ⭐⭐⭐ On-Prem connectivity is provided in 3 different ways for all network setups mentioned above.
Cloud Interconnect Network Documentation only mentions that Cloud Interconnects should be done similar to the HA VPN setup. So it seems like the basis is there, but no specific support for setting up a concrete inter-connect. ⭐⭐⭐ It supports Direct and Partner Interconnect.
Managed Key Vault ⭐⭐⭐ A Cloud KMS is rolled out to every environment so e.g. all production services have a way to reliably and securely share secret keys. ❌ One of the sample projects creates a KMS, but only within the project.
Automation in CI/CD ⭐⭐ Supports automation with GitHub Actions, GitLab, and Source Repo. An in-depth look into the terraform code might be needed to get it to work. While it provides a great benefit, it could use more directed documentation. You can add this automation whenever you like. Even if you applied Terraform manually for some time, you can still add CI/CD later on. ⭐ Cloud Build or Jenkins can be used to roll out the Foundation. Additionally, Google Cloud Build seems to be set up for all end-user projects, so they can also quickly start with CI/CD. With Cloud Build and Jenkins, only 2 established CI/CD solutions are provided. Modern CI/CD tools such as GitHub Actions or GitLab are not supported.Documentation for rolling out the modules is heavily centered around using a CI/CD tool. So you are triggered to use it right from the beginning instead of growing your solution to using CI/CD over time to keep complexity as low as possible at the beginning.

GCP Landing Zone Non-Functional Comparison

Checklist Fabric FAST Example Foundation
Extensibility/Modularity/Scalability ⭐ The checklist generates Terraform code to roll out the resource hierarchy, networking, audit logging, and a basic IAM approach. Sadly org policies are not applied via Terraform. In general, you can extend those easy-to-understand templates with whatever you need. But they don’t provide any sophisticated structure or approaches that help you scale your foundation to something big. ⭐⭐⭐ It contains several ready-made terraform modules that the different stages utilize. Each stage has outputs that are used as input variables for the next stage. It can therefore be extendable as long as a “contract” regarding input and output variables is followed. tfvars files are created and uploaded to GCP buckets that can be accessed by different stages. ⭐⭐ Terraform code is structured into different stages. So this Terraform Module structure supports scaling. The generated default projects might be a bit cumbersome to be replaced by the projects you really want to have. In general, the example foundation is not as configurable as Fabric FAST and e.g. relies quite heavily on a folder structure based on the different environments.
Terraform ⭐ Terraform is actually generated for most of the configs, but e.g. org policies are not part of that terraform code but have to be applied manually in a guided dialog in the GCP web console. Additionally, the Terraform modules are very basic and don’t provide a structure that is ready for scaling them to way more modules in the future. ⭐⭐⭐ A sophisticated structure for the Terraform modules is applied. Especially structuring them into different stages makes it scalable. Additionally transferring input from one module to the next is handled in a reasonable way. Using TerraGrunt might enhance this transfer even more. ⭐⭐ It’s a structured and sophisticated Terraform structure. But transferring data between the steps must be done completely manually. A more automated approach like TerraGrunt is not being used here.
Learning Curve ⭐⭐⭐ The learning curve is very low. You simply follow the wizard and everything you need to know is explained to a sufficient degree on the wizard pages. That way you can easily and quickly understand what it does and how to configure it. ⭐ Documentation guides through the stages, but several questions and details remain open and you have to look into the TF modules to understand details or how to customize certain areas. Especially the way IAM and PAM are handled is not documented well and is not easy to understand. Also, parameter documentation is very basic and is therefore not always helpful. ⭐ Documentation in the READMEs for the different stages is rather short and only explains the most important things. Details have to be read up in the general Google CFT docs. But it is also quite hard to understand what the modules are doing while applying them, as the steps you have to do manually are not providing you insight into the modules. It’s just some git, copy, etc commands you have to execute step by step for every stage.
Community ⭐ As the checklist is well guided by the wizard and in general it creates easily understandable Terraform modules there is not really a need for a community around it. ⭐ it is really hard to currently find resources on Fabric FAST besides the documentation by Google. Looking at the contributors and the activity on the Repo it is quite active. There are around 70 internal and external contributors to that repository. We expect the community to grow in the future. ⭐⭐ It seems to be the most commonly used solution for GCP at the moment. You can find several blog posts about it and more.
Time To Success ⭐⭐⭐ If you have a user who is Super Admin and Org Admin at hand you can really quickly set up your landing zone. Within a few hours you have everything configured and applied and you understand what it does. ⭐⭐ Considering the quite big scope of Fabric FAST, you can also rather quickly achieve your goal of a landing zone. It most likely will take you 1-2 days to go through all stages and apply them according to your needs and to roughly understand what is deployed. For understanding the Landing Zone you built here more deeply requires a few more days. ⭐⭐ Google says you can set up your foundation within a day. Looking at the problems we had when trying to roll it out, I think it takes longer. The process is also quite error-prone as you have to execute that many commands manually. Understanding more deeply how the Landing Zone you applied here behaves exactly requires additional effort.

Which GCP Landing Zone Should I Pick?

The Terraform Example Foundation from the CFT should not be used anymore as Fabric FAST supersedes it and provides a way cleaner and usable approach. With the Example Foundation you have to execute >20 commands per stage manually (there are 6 stages in total). We also heard from one of the Google Consultants, that Fabric Fast is the direction they want to go to in future. As we tried to roll out the Example Foundation, we noticed that it is way more painful to use than Fabric FAST and it feels way more hacky.

The Google Cloud Setup Checklist is a nice and small solution that fits well for smaller companies or companies just wanting to get started quickly with their Cloud Journey in a reasonably secure environment. It also allows growing your foundation step-by-step by extending the generated Terraform modules to your needs.

But, if you have a really big cloud foundation in mind, the Terraform Modules provided by the Cloud Setup Checklist might not suffice to scale them to something large. It also doesn’t contain solutions for advanced problems many companies face. If you want to grow your Cloud Foundation Landing Zone, you should better consider starting with Fabric FAST right from the beginning as it applies a sophisticated IAM and PAM concept and a scalable structure to organize your Terraform modules with those stages. It also provides more features that make sense for many companies.

Starting with the Google Cloud Setup Checklist first, and adopting Fabric FAST later on is also a feasible option. Both use the same user groups and adopting the resource hierarchy, networking, and audit logging should also be possible as they don’t differ drastically.

Did this blog post help you decide which Landing Zone Solution you will apply to our GCP Org? Did you already gather your own insights to building a GCP Landing Zone and want to back up, add or discuss insights from this blog post, please do so and leave a comment! We look forward to hearing about your experience.


Automated Self-Service for Azure Networking Services

Automated Self-Service for Azure Networking Services

Automated Self-Service for Azure Networking Services

Summary: Many cloud and networking teams struggle to provide their organization’s application teams with the Azure networking services they need. Why is that? As organizations strive to move to the cloud the high demand for networking services meets manual processes. The result is a real bottle-neck that slows down cloud adoption. Read this article to learn how to offer Azure networking in fully automated self-service with a solution developed by meshcloud. Additionally we offer a free demo.

The Problem: High demand for integrating applications into Azure meets manual network processes creating a cloud adoption bottle-neck

Organizations that move to the cloud and to Azure specifically encounter a high demand for integrating applications into their virtual networks. To offer on-prem or secure cloud connectivity they might build a hub-and-spoke architecture, having to create the spokes manually every time. A real bottleneck for the organization's cloud transformation and not a scalable solution.

The solutions offered by Azure are complex and lack central transparency and control. Organizations need to be able to offer Azure connectivity in a scalable and secure way that allows central control.

Most organizations either don’t have an automated solution implemented at all or don’t know how to realize the architecture for Azure networking services and offer them to their application teams.

Often Network Engineers use an ITSM or even email and phone to give the access to virtual networks the application teams need. They set up networks manually for each request they get.

In a better case scenario they get pull requests for a terraform deployment from application teams and approve them to roll out networking architecture.

The Solution: meshStack and UniPipe Service Broker let you provide Azure networking in fully automated self-service

With meshStack - meshcloud’s Cloud Foundation Platform - and UniPipe - meshcloud’s GitOps-based Service Broker solution - it is possible to offer Azure networking in fully automated self-service. The central cloud team and the network engineers can set up an Azure networking service broker in less than an hour. With this in place the application teams can book and use the integration of their application into the organization’s virtual network within minutes.

How it works

Central Cloud Team & Network engineers

  1. Create a Git repository that will be used for GitOps by UniPipe Service Broker. Data about all requested services and their status is stored in it.
  2. Add the Azure Networking Service Terraform Module provided by meshcloud to this repository. If needed you can modify the Terraform modules to your needs.
  3. Deploy and with only a few steps configure UniPipe Service Broker and UniPipe Terraform Runner docker containers.
    You can use Azure IPAM to automatically assign unique IP ranges.
    OR you can add a manual step to the Service processing in which a network operator assigns an IP range.
  4. Register the new Service Broker in meshStack, so its services appear in the marketplace.
  5. Add the service as a required service to your meshLandingZone, which will be applied after creating a new project.
  6. Enjoy your running and integrated Azure Networking Service

Application Team

  1. Create a new project in meshStack.

  2. During project creation you can pick a plan (On-Prem connectivity or Cloud-only connectivity), provide information about the vNet size and the target location in Azure.
    Automated Self-Service for Azure Networking Services

  3. After project creation the network will be successfully deployed into your Azure subscription and you can start using it within your application.

Conclusion: High demand needs automated supply to keep your cloud adoption goals in focus

meshcloud’s solution solves your scalability challenges when it comes to integrating applications into your organization’s Azure networking. Automating the provisioning of Azure networking services removes a common bottle-neck and enables networking and application teams to reach their cloud adoption goals.


Playing Field

Cloud Foundation: 3 valuable Players on the Field

Building Cloud Foundations can be cumbersome and tedious. In this post we’ll introduce 3 of our offerings in that field that will make your life easier.

If you are an Enterprise Architect and/or responsible for your organization’s Cloud Center of Excellence or Cloud Foundation Team this post is for you.

It will show you ways to accelerate your Cloud Journey, provide insights on Cloud Foundation best-practices and finally demonstrate how our offerings play together to help you build the best Cloud Foundation.

The Cloud Foundation Maturity Model – Getting Clarity

As a member of your Cloud Foundation Team, you may have come across the Cloud Foundation Maturity Model (CFMM). It’s a strategic model that helps you understand the capabilities you’ll need to build up during your Cloud Journey, regardless of which clouds you use, where you’re currently at or what approach to implementation you have taken.

You can consider it the coach on the playing field. It gives you guidance, shows where you’ll want to go and provides insights into different implementation options that will get you there.

We have used this model successfully with leading cloud-native organizations from various industries.

Building Cloud Foundations is an Iterative Process

Lots of organizations we work with run thousands of applications in the cloud, managed by a central Cloud Foundation Team. However, they didn’t get there within a day. Implementing a Cloud Foundation is best approached with an iterative approach. You start with the basics and implement more and more sophisticated capabilities over time as you get to know more about your users and their requirements.

The Cloud Foundation Maturity Model helps you to break the journey down into small steps that systematically build upon each other.

It’s not only about how far along the Cloud Journey you are, but also what type of vehicle you’re using

When Cloud Foundation Teams are faced with large-scale cloud migration projects, they know that whatever Cloud Foundation capabilities they build they’ll have to be highly automated in order to keep up with the upcoming scale of cloud demand.

That’s why we cover two dimensions when it comes to maturity within our Cloud Foundation Maturity Model:

  1. Journey Stage: Varying from Essential building blocks (1) to Industry Leading capabilities (5)
  2. Implementation Maturity: Varying from manual to fully automated

Assessing both brings you valuable insights when evaluating the current state of your Cloud Foundation and that’s exactly what the Cloud Foundation Maturity Model can be used for.

As a result, you’ll have a structured analysis of your Cloud Foundation, demonstrating your achievements as well as areas you’ll need to improve on a single page, which makes it a great tool for internal communication.

Collie – A Trustworthy Helper On Your Way To Cloud Foundation Maturity

Most organizations start their cloud journeys in high spirits on a green field. By the time you realize that you need proper cloud governance and decide to establish a Cloud Foundation, the once green grass has turned into a brownfield landscape. Collie is an open-source multi-cloud CLI that helps exploring and sorting, preparing for systetmatic management. It’s built for power-users, single player.

Collie CLI easily provides multi-cloud transparency on cloud tenants, corresponding access rights, tags and cost information. In regard to the Cloud Foundation Maturity Model it will help you to implement the following building blocks:

To fully automate your cloud foundation capabilities and establish collaboration between the Cloud Foundation and your DevOps teams, you’ll need to go one step further and use a platform like meshStack that reflects this organizational model.

meshStack – Your Cloud Foundation Platform

At meshcloud, we focus on enabling DevOps teams to use cloud and speeding up their applications’ time-to-market. Providing self-service access to native cloud tenants like AWS accounts, GCP projects or Azure subscriptions is critical to achieve this.

We know that every organization is unique and comes with specific requirements, especially in regard to the integration of existing IT Landscapes. Our aim with meshStack is to help you get the basics right and enable you to build upon them.

That’s why a lot of Cloud Foundation capabilities come out-of-the-box, while others can flexibly be adapted to your organizations’ needs.

In general there are 3 ways meshStack can help you to implement Cloud Foundation Building Blocks.

  • meshStack provides this Cloud Foundation Building Block out-of-the-box

    Outcomes Graphic

    Example: When using meshStack in a multi-cloud setup, you’ll have a Self-Service Multi-Cloud Tenant Database, out-of-the-box.

  • meshStack enables strong facilities for an easy implementation of that building block

    Outcomes Graphic

    Example: With Landing Zones and Services you’ll have everything you need to implement Modular Landing Zones.

  • There are established solution patterns that facilitate the implementation of this building block, when using meshStack

    Outcomes Graphic

    Example: There is an established solution pattern that will help you provide managed Service Accounts with meshStack.

The following graphic demonstrates in detail, which Cloud Foundation Building Blocks are implemented by meshStack in which of the 3 aforementioned ways:

meshStack implements

In The End It’s About the People

Our offerings aim to help organizations throughout their entire Cloud Foundation journey:

  • From understanding and defining the Cloud Foundation for your organization based on our Cloud Foundation Maturity Model
  • to analyzing and understanding existing cloud landscapes with Collie CLI
  • all the way to implementing large-scale Cloud Foundation Platforms to manage thousands of teams and applications based on meshStack.

However, establishing a Cloud Foundation within an organization is not only about building up the relevant capabilities and deciding on implementation options. It also is a huge organizational shift that requires involvement of all stakeholders and great communication across teams and up to the C-Level.

By allowing organizations to easily experience the power of self-service and providing means for internal communications, we want to enable Cloud Foundation Stakeholders to drive acceptance for change throughout the entire organization in order to pave the way for a new way to organize IT.


The Ultimate Resource for Building a Cloud Foundation

With cloudfoundation.meshcloud.io meshcloud is launching a documentation for all cloud and enterprise architects looking to establish a cloud foundation and bring cloud adoption to the next level.

What is a Cloud Foundation?

One central piece of successful cloud transformation is the creation of a central cloud team: Cloud Foundation, Cloud Competence Center or Cloud Center of Excellence - many names, one core concept:

Centralizing cloud governance to enable more productive, more agile, and more innovative use of cloud.

The Cloud Foundation Maturity Model

Building cloud foundations is our daily business at meshcloud. With meshStack, we provide a technical platform for cloud foundation teams.

With our Cloud Foundation Maturity Model, we offer a framework for organizations to assess the state of their cloud adoption, validate their strategy, and plan a road map.

Your Go-To Resource for Building a Cloud Foundation

With our new website cloudfoundation.meshcloud.io, we make the Cloud Foundation Maturity Model available and open it up for debate to develop and refine it further.

Cloud Foundation Buiding Blocks on interactive Maturity Model
Explore the Cloud Fundation Maturity Model interactively on our website.

In over 50 actionable building blocks – covering Security and Compliance, IAM, Cost Management, Tenant Management, and the Service Ecosystem – our website describes the capabilities needed to mature a Cloud Foundation.


Log4Shell: meshcloud NOT affected by Log4J Vulnerability

Researchers have found a critical zero day vulnerability in the Apache Log4J library. Our solution meshStack is NOT affected. Our engineers checked the meshStack services and dependencies and confirmed that our solution does not include affected Log4J modules.

What is the Problem with Log4J?

Apache Log4J is a widely used library for logging errors.

The recently discovered vulnerability CVE-2021-44228 - dubbed Log4Shell or LogJam - was given a CVSS severity level of 10 out of 10. It's a vulnerability that seems to be easy to exploit and enables attackers to execute code remotly.

The german Federal Office for Information Security (BSI) warns of the Log4J vulnerability with the highest warning level "4/Red". It goes on to say that "the extent of the threat situation cannot currently be conclusively determined." The BSI also warns that the vulnerability is already being actively exploited, for example for cryptomining or other malware.

When are you affected by Log4Shell?

The first important part is, that the vulnerability is located in the log4j-core module. Other libraries like Spring Boot are only using log4j-api by default and are therefore not affected by this vulnerability (see Spring Boot's blog post on it).

The vulnerability can only be exploited, if your application logs input that was provided by users in any way (e.g. via an API or via a UI). They could provide certain messages that lead to Log4J executing some code from remote which can be used to access your server and execute some malware on it. As long as you and the libraries you are using are not logging any input given by users, you should not be affected by the vulnerability. But especially with the usage of other libraries it might be hard to judge on whether you are actually affected or not. So if you are using the Log4J for logging, you should - regardless of whether you think that messages provided by users are logged - follow the recommendations below.

Current Recommendations

The Apache Foundation recommends to update the library to version 2.15.0 or - if not possible - to follow the instructions on their Log4J security vulnerabilities page to mitigate the risk.


Security as Code

meshcloud receives funding for the cloud security approach "MultiSecure" by the German Federal Ministry of Education and Research (BMBF)

It’s been a while since we announced that we’ve been funded for our MultiSecure project. We are still very excited about the great news and have already been working hard on putting our vision into practice: We want to enable organizations to code their cloud security regulations along with their applications and infrastructure.


Additional Information:
Starting in April 2020 meshcloud receives funding by the German Federal Ministry of Education and Research (BMBF). The funded project with the title “MultiSecure” aims to create a declarative technology to describe secure multi-cloud infrastructures and organizations. It addresses the need of organizations to establish an effective way to handle security requirements as well as control on the infrastructure in their cloud transformation.


Implementing secure cloud configurations is a major challenge for large organizations

By now most large organizations already use cloud computing infrastructure for application development. Flexible on-demand access to different types of cloud resources as well as a shift towards agile methodologies enable them to accelerate their software delivery capabilities and drive innovation. Cloud service providers like Amazon AWS, Google Cloud Platform or Microsoft Azure provide a vast and continuously growing portfolio of cloud services to address these needs. As the adoption of cloud computing increases, cloud environments become more complex and are harder to control. Looking at the market, we observe that in many cases the “experimental” use of the technology has been overcome, requiring consistent, automated processes to allow for a further scalable adoption.

Security Responsibilities have shifted and decentralized across the organization

We are facing increasingly complex cloud environments. In addition to that a shift in responsibilities has occurred: While central IT departments used to be responsible for the majority of security aspects on the infrastructure layer, this responsibility has shifted and decentralized. Many services are directly provided by the cloud providers rather than the central IT departments, relieving central IT from part of the responsibility. To learn more about Shared Responsibility, check out our (Guide on Cloud Security and Compliance). On the other hand DevOps teams that use the cloud have to take care of the security on the infrastructure and application layer. Mistakes in the configuration of infrastructure are security-critical. Incidents as happened at Capital One demonstrate the risk.

Cloud Security Responsibilities

This shift in responsibility raises 3 questions:

  • How can central IT departments achieve control on the organization’s cloud infrastructure ?
  • How can organizations handle policies across clouds and across teams ?
  • How can organizations enable DevOps teams to focus on functional requirements of their application ?

Without consideration of these questions, an organization is likely to lose itself in shadow IT, immense complexity and an enormous non-functional overhead in application development.

Cloud Environments are complex, dynamic and durable

Let’s look a bit deeper into the organizational context of a cloud project. Here is an exemplary process of providing a cloud environment to a DevOps team:

  • A team member, most often a team lead, requests a cloud environment for a specific cloud platform for his team.
  • The environment, also known as a cloud tenant, has to be created.
  • Permissions on different levels (e.g. admin/developer) have to be provided to the team members.With these permissions in place the team will have access to their cloud environment and the corresponding services.
  • DevOps teams have to demonstrate compliance with the organization’s security frameworks to get an approval to bring their application to production. Therefore, before deploying an application to the cloud environment, cloud environments are usually configured to follow corresponding security controls.

Mostly, these configurations are not workload-specific, they cover organizational aspects of different areas like identity and access management, server geography, service configurations or cloud budgets. These are some examples:
Cloud Configuration Examples

Defining, implementing and maintaining them over time is a major challenge (Read more on this in our post on the Cloud Landing Zone Lifecycle). Especially at a large scale, organizations face the following difficulties:

  • In some cases, DevOps teams receive access without prior configuration of the cloud tenant. The compliance then has to be approved retrospectively leading to additional effort and change requirements when the application has already been deployed, rather than preventing them to occur.
  • If the cloud tenants are configured manually and by each team individually there is a high risk for inconsistencies, due to mistakes.
  • Security controls are mostly defined abstractly and in natural language. Their interpretation is often up to the person that technically implements them which again leads to inconsistent results, even if done correctly.
  • Cloud service providers offer different ways to put these configurations into place. For multi-cloud environments this makes it even harder to implement consistent policies across different cloud service providers.
  • With large amounts of cloud tenants these inconsistencies multiply and with no system in place that provides cross-cloud transparency, an effective implementation and control of the measures is hard to achieve.


Today’s IT organizations have to find the right balance between, which leads to a demand for new security approaches:
the agility and technological freedom DevOps teams need to leverage the cloud for a better software delivery performance
AND
the control and governance an organization must have to on their infrastructure to act responsibly and mitigate security risks. Finding this balance requires new approaches to IT security.

In a perfect world security rules and requirements are unambiguous and easily interchangeable between Stakeholders

In many cases policies bring together different stakeholders and their implementation requires the cooperation of multiple departments within an organization and beyond it. Let’s consider a compliance department: They define policies in natural language. These policies then have to be implemented by IT teams and will later be audited by an external party. While standards like the ISO/IEC 27000 family have led to alignment and a common vision of best practices in the field of information security, we still face a lot of uncertainty, when it comes to the adoption and implementation of these standards within the organization in connection with new technologies and working methods.

Textual explanations are oftentimes ambiguous and it is hard to judge, whether a control has been appropriately fulfilled or not.

In a perfect world, security organizations would be formalized, e.g. put in “code” to avoid unstructured and intransparent document battles. Rules and requirements would be clear and therefore could be communicated precisely. Suppliers, customers and companies would have a common basis for communication.

MultiSecure unifies and formalizes security and organizational rules to establish a consistent and transparent security framework for organizations

With the MultiSecure project, meshcloud aims to overcome this uncertainty and increase transparency when implementing security policies within the organization. MultiSecure bridges the gap between clearly defined security controls, custom organizational processes and the cloud infrastructure providers.

The idea – A declarative projection of the organization

The idea of MultiSecure is to describe organizational elements and their relationships as code in an open and reusable format - a declarative manifest that represents the desired target state of the organization. The information in that manifest follows a clear structure and can be handled as source code:

  • It can be versioned,
  • it is at all times clear who made changes to the target state definition and
  • it can automatically be compared and synchronized with the actual state of the multi-cloud environment.

MultiSecure allows to centralize this information in an open format, instead of squeezing the organization into the envisaged organizational models of the cloud providers and therefore maintaining multiple proprietary organizational models in parallel and distributed. It builds a projection of the organization that can be consumed by different systems.

This is where meshcloud and our software platform meshStack come into play. meshStack consumes this organizational information either manually via our user interface or via API and automatically replicates it into the different cloud service providers, taking into account their specific native tools, services and best-practices.

The Benefits – A comprehensive IT security framework and avoidance of vendor lock-in

We already mentioned the benefits of having code to avoid ambiguities in terms of interpretation of security controls. Here are the main benefits we see regarding the overall governance of IT infrastructure within the organization.

1. An integrated security concept:
By enabling organizations to define policies centrally and in an open format, that can be applied to various cloud providers, MultiSecure provides an integrated security concept for the use of cloud technologies.

2. Reducing vendor lock-in:
Uncoupling organizational processes and security requirements from a specific cloud provider, empowers organizations to keep sovereignty over their infrastructure and choose their preferred cloud provider(s) self-determently.

3. Reducing IT security risks with preventive measures:
Configuring cloud environments to comply with security requirements, before handing them over to their users (DevOps teams) is one of the core concepts behind MultiSecure. It does not only prevent misconfigurations that could lead to security breaches, but relieves DevOps teams from non-functional requirements.

4. Made for scale and a sustainable IT strategy:
The declarative nature of MultiSecure allows for a sustainable and scalable security strategy. Cloud environments can be created fully automated fulfilling a rising demand for infrastructure of any provider. Furthermore, the approach takes into account the lifecycle of applications and policies, with mechanisms for updates and long-term operations in place.

The scope – Infrastructure as Code vs. Security as Code

The concept of a declarative manifest is not new to the cloud world. Known as “Infrastructure as Code” it has been popular for the deployment of cloud infrastructure. We are not aiming to cross this field. That is why we consider workload out of scope of the project. There are already great solutions around (e.g. terraform, ansible) to define resources within cloud environments. As meshcloud, the MultiSecure project focuses specifically on the organizational aspects of security and governance and can be considered the “terraform” for security and the organization.

Join the MultiSecure Community to shape the Future of Cloud Security

We strongly believe that this project will benefit from the contribution of diverse stakeholders. Even before the official launch of the project, we’ve received excellent and supporting feedback from customers as well as partners. We’d be more than happy to have you on board for our mission, too.

To keep up to date, we kindly invite you to

We are interested in your use cases. If you see any touchpoints to MultiSecure, we’d be more than happy to discuss and get in touch with you. Reach out to us with your questions.


Busy beehive as example for continous work

Corona Update: meshcloud operates at full capacity

How meshcloud is ensuring operating at full capacity and accompanying our customers through these times to continue their digital journey

Read more


How to apply for a technical role at meshcloud

On this page, we want to give you an overview of our values and interview process hiring for technical full-time positions in our team. We hope this guide helps you navigate the process successfully and answers your questions. Should you have any more questions, please don't hesitate to reach out at jobs@meshcloud.io.

We believe that hiring is as much about us getting to know you than it is about you getting to know us. Our application and interview process is thus designed to give both of us a chance to evaluate your fit for a position at meshcloud.

Overview and TL;DR

  • Application with CV and Portfolio (Github, Stackoverflow, etc.)
  • Phone Interview
  • On-Site Interview at our Office & Design Exercise
  • On-Site "MVP Test" with your future colleagues
  • Feedback and offer

Stage 0: Your Application

Present yourself and your skills in the best possible light. Let us know why you're interested in working for meshcloud and consider yourself a good fit for our team. Tell us about your values, achievements and contributions you have made in prior roles. If you're a recent graduate, tell us about a project you've worked on that you're proud of. Even more than your concise resume, we like seeing a sample of your work and abilities. Send us a link to your projects, your stackoverflow or github profile.

Please do not include information on your resume that we don't need to evaluate your application. All that matters to us is your qualifications and personality. We do specifically ask you to not include a photo, gender, marital status or religious orientation.

When we do list the technologies we work with in our job profiles, we always separate between "must have" skills
and "nice to have" skills. We believe that every technical skill is valuable. So while we may not use [insert obscure language] right now, there's a good chance you have learned something valuable and transferrable using it. So, please do include it on your CV! We're open-minded when it comes to integrating new tech & tools into our stack.
Our most recent addition is dhall.

1st Stage: Phone Interview

You'll meet one on one with the future manager of your position for a structured 30 minute phone interview.
We expect you to tell us briefly about yourself and your experience. We'll discuss the role and answer any questions you may have about the position. The second half of the interview is a set of technical questions that helps us get an indication of your skill level in competence areas relevant for the job. We're not looking for textbook answers and you should not prepare specifically for this part.

2nd Stage: On-Site Interview

The on-site interview typically lasts for 2-3 hours. You'll get to visit our office and meet members of the team you may be working with in the future! You'll also meet members of other teams at meshcloud.

We'll discuss in-depth about your prior experience and will together walk through a technical design exercise appropriate for the role. We use this exercise to see your problem-solving process and how you leverage your experience, skills and knowledge to solve the task at hand. This may also involve some whiteboarding or scribbling on paper, but we'll not ask you to come up with syntactically correct code on paper. The challenges are hands-on and real things we're working on, so they will allow you to discover about the things we work on and how our tech stack looks like.

3rd Stage: MVP Build

We don't belive take-home "coding exercises" or "coding tests" provides you with a good idea of how we work at meshcloud.
Instead, we want to give you a chance to experience being a part of the team and see how we work first hand.

So what we do is that we will together develop a small and focused "minimum viable product" (MVP) related to your role. We typically start in the morning and walk through the task at hand. The goal is to produce a working prototype in 3 hours.

When building the prototype, we totally expect you'll have to cut some corners. Of course you'll discuss requirements and implementation questions with your colleagues. When we start in the morning, we invite you out for lunch with the team and review your results together after we return. In review you'll present your approach and results, tell us about the corners you cut and what would be left to finish the work to your own quality standards.

If you're a remote candidate or considering relocation to work with us in Frankfurt am Main, we will try to schedule the On-Site Interview and MVP Test for the same day.

Final Stage: Feedback and Offer

You'll typically hear from us within a week of your interview whether we want to offer you the position. We know that you'd rather hear sooner than later whether your interview with us was a success. However, we want to make sure we give every application the attention it deserves. After your interview we collect feedback from all colleagues that got a chance to know you. We also give our colleagues some time to make up their mind and offer additional feedback after the experience has settled for a bit.

You want to learn more about us?

Please check our open positions and our company page on Stackoverflow.