Cloud Native
A cloud-native app has been designed and written specifically to run in the cloud and take advantage of this type of infrastructure's properties. An organization can consider itself “cloud native” when it has also adopted supporting DevOps workflows and practices to enable greater agility, increased speed, and reduced issues for both the app and the organization.
In common cloud-native app architectures, each is composed of several loosely-coupled and highly-cohesive microservices working together to form a distributed system. Loosely coupled means that an individual microservice can be changed internally with minimal impact on any other microservices. Highly-cohesive microservices are built around a well-defined business context, and any modifications required are typically focused on a single area of responsibility or functionality.
Cloud native applications are often packaged and run in containers. The underlying cloud infrastructure often runs on shared commodity hardware that is regularly changing, restarting, or failing. This means that a microservice should be designed to be temporary. It should start quickly, locate its dependent network services rapidly, and fail fast.
May 18, 2020 | 11 min read
Development Environments, Microservices
How do you set up a product development environment for microservices and Kubernetes? While the tooling and infrastructure for building traditional web applications has been highly optimized over time, the same cannot be said for microservices.
In particular, setting up a product development environment for microservices can be considerably more complex than a traditional web application:
Your service likely relies on resources like a database or a queue. In production these will often be provided by your cloud provider, e.g. AWS RDS for databases or Google Pub/Sub for publish/subscribe messaging.
May 14, 2020 | 6 min read
Kubernetes
Practically every cloud vendor or private cloud solution supports the deployment and operation of the Kubernetes container orchestration framework. Since the initial release of Kubernetes by Google in 2014, a large community has formed around the framework, often facilitated by the organisation that is now the steward of the project, the Cloud Native Computing Foundation (CNCF).
Kubernetes has been widely adopted as a container manager, and has been running in production across a variety of organizations for several years. As such, it provides a solid foundation on which to support the other three capabilities of a cloud native platform: progressive delivery, edge management, and observability. These capabilities can be provided, respectively, with the following technologies: continuous delivery pipelines, an edge stack, and an observability stack.
Starting with Kubernetes, let's explore how each of these technologies integrates to provide the core capabilities of a cloud platform.
April 16, 2020 | 21 min read
Cloud Native
Description
Everyone building or operating cloud native applications must understand the fundamentals of security issues and modern threat models. Although this topic is vast, in this talk Nic and Daniel will focus on the end-to-end communication and higher-level networking threats, and explore how the combination of an edge proxy and service mesh using TLS and mTLS can be used to mitigate many man-in-the-middle attacks.
Transcript
April 14, 2020 | 38 min read
Kubernetes
Learn about the four key technologies you need to build your Kubernetes-based platform.
This week, we hosted a webinar “Building a Technology stack for your Kubernetes-Based Platform” with Daniel Bryant, Head of Dev Rel at Ambassador Labs.
With adopting a cloud native approach being the new normal for tech organizations, new technologies and new workflows are required. In order to be successful, an organization needs to have the perfect combination of the two. In addition, it is essential to create a supporting cloud platform. In this webinar, Daniel explains that within the supporting cloud platform, there are four key requirements:
April 9, 2020 | 2 min read
Edge Stack API Gateway
Your Kubernetes cluster requires that there be a "hosted zone" in Amazon Route 53 which is an Amazon service that acts as a domain registrar and DNS management system. When a Kubernetes cluster is provisioned a number of DNS records are created such as "api.$CLUSTER_NAME.$DOMAIN" (e.g. api.foobar.example.org). Unfortunately configuring DNS is a bit of a pain. This guide exists to walk you through the process which is as follows:
Get a domain (either buy one or reuse an existing domain (We strongly recommend buying a new one or reusing an unused one that already belongs to your Route 53 account.
Ensure DNS is setup properly.
April 9, 2020 | 2 min read
