Skip to content

2022

  • 12 min read

Introducing Amazon Web Services (AWS)

Hello everyone, my name is Victor Leung and I am an AWS community builder. In this article, I would like to introduce Amazon Web Service (AWS). You may be wondering, what is AWS? It is the world's most comprehensive and well-adopted cloud platform. Customers trust AWS to power their infrastructure and applications. Organisations of every type and size are using AWS to lower costs, become more agile and innovate faster.

AWS provides on-demand delivery of technology services via the internet with pay-as-you-go pricing. You can use these services to run any type of application without upfront costs or ongoing commitments. You only pay for what you use.

Moreover, AWS gives you more services and more features within those services than any other cloud provider. This makes it faster, easier and more cost-effective to move your existing application to the cloud and to build anything you can imagine.

You can rely on AWS's globally deployed infrastructure to scale your application to meet growing demand. There are so many regions in the world, how to choose? You can start with the region closest to you and your customer. A region is a physical location in the world that consists of multiple Availability Zones. Each availability zones consist of one or more discrete data centres, each with redundant power, networking, and connectivity, housed in separate facilities. In the future, if your company expands to other regions, you can take advantage of AWS facilities as well. The AWS Cloud spans 84 Availability Zones within 26 geographic regions around the world, with announced plans for 24 more Availability Zones and 8 more AWS Regions.

As for the computing power on the cloud platform, there are several types to choose from. You can use the EC2 virtual server service to deploy your server on the platform. And there are so many types of EC2, how to choose? In fact, it is decided according to your needs, the four aspects are the CPU, memory, storage and network performance. According to the type, age, capability and size, there are certain naming conventions, such as M5d.xlarge.

Generally speaking, for the instance selection process, you can start with the best-guess instance. Then determine the constrained resources. For example, C5 instances are optimised for compute-intensive workloads. It is suited for high-performance web servers. It has cost-effective high performance at a low price per compute the ratio. Besides, for M5 instances, they are general purpose instances. It has a balance of compute, memory, and network resources. It is a good choice for many applications.

Once you started an EC2 instance, you may change the instance type as well. You can resize for over-utilized (the instance type is too small) or under-utilized (the instance type is too large) cases. This only works for EBS-backed instances. The steps are 1. Stop instance 2. Instance Settings -> Change Type 3. Start Instance. You cannot change the instance type of a Spot Instance and you cannot change the instance type if hibernation is enabled.

There are a couple of available CloudWatch metrics for your EC2 instances:

  • CPUUtilization: the percentage of allocated EC2 compute units
  • DiskReadOps: completed read operations from all instance store volumes
  • DiskWriteOps: completed write operations to all instance store volumes
  • DiskReadBytes: bytes read from all instance store volumes
  • DiskWriteBytes: bytes written to all instance store volumes
  • MetadataNoToken: number of times the instance metadata service was successfully accessed using a method
  • NetworkIn: number of bytes received by the instance
  • NetworkOut: number of bytes sent out by the instance
  • NetworkPacketsIn: number of packets received by the instance
  • NetworkPacketsOut: number of packets sent out by the instance

Besides, you can install the CloudWatch agent to collect memory metrics and log files.

When purchasing EC2, there are many options. You can start with an on-demand instance first, billed by the second, with no long-term contract. After you try it out in the future, you can choose a more cost-effective reserved instance and pay for a long-term lease of one to three years, which will save you money in the long run.

After choosing the purchase method, you can put the EC2 virtual machine into the auto-scaling group. When the demand increases, the number of EC2s can be increased at the same time, thereby increasing the computing power. When the peak period is over, such as when there is no traffic in the early morning, the number of EC2s can be automatically reduced. This automatic scaling function can be scaled independently according to different indicators, and this function is free to use.

For EC2 Load Balancing, by default, the round robin routing algorithm is used to route requests at the target group level. It is a good choice when the requests and targets are similar, or if you need to distribute requests equally among targets. You can specify the least outstanding requests routing algorithm, with consideration for capacity or utilization, to prevent over-utilization or under-utilization of targets in target groups when requests had varied processing times or targets were frequently added or removed. If you enable sticky sessions, the routing algorithm of the target group is overridden after the initial target selection.

Elastic Load Balancer (ELB) can be used to automatically assigned to one or more availability zones, and at the same time, it can check the health status of the backend servers, and increase or decrease resources horizontally according to traffic requirements. There are also several different options for load balancers. For Application Loan Balancer (ALB), which is configured according to the OSI layer 7, which is HTTP. Other load balancer can also be distributed through the fourth layer of the network OSI, using the protocols of TCP and UDP, as well as the distributor of the gateway.

Suppose your business is unlucky to encounter a large-scale accident, such as a natural disaster, an earthquake, damage to a data centre, a technical impediment, or a human error, such as an employee running a command rm -rf deletes all the data, so what should you do? Actually, there are different methods, and there are also different restoration times and origins.

As for the different methods, different costs would be charged. The higher the cost, the faster the recovery. If your business can tolerate a few hours of service interruption, a normal backup and restore scenario is fine. But if it doesn't work, and it takes a few minutes to restore service, then it's a matter of replicating an identical environment in a different region, and in a standby state.

Let me give you an example, such as deploying a website to an environment in Singapore, and deploying a backup environment in Hong Kong at the same time. Through the Route53 domain name system, the domain name is pointed to the Singapore region. When a problem occurs in the Singapore area and the entire area cannot be used, the domain name can be transferred to the Hong Kong area immediately, and normal services can be resumed. The process can be changed manually or automatically, or even distributed proportionally or on a user-by-user basis.

However, operating in two regions is relatively expensive. For generally small-scale problems, such as component failures, network issues, or sudden increases in traffic, deploying to two or more Availability Zones is fine. When a zone is unavailable, it is immediately moved to another available zone, and data can be independently replicated.

Regarding to database, you can choose RDS, which is compatible with MySQL database and can be resized. RDS is a hosted service that handles patching, backup and restore functions for you. In the future, you can also consider using Aurora. The throughput can reach about three times, but the price is also more expensive, depending on whether you want to achieve the performance of a business database.

RDS allows multi-AZ deployments, which provides enterprise-grade high availability, fault tolerance across multiple data centres with automatic failover, and synchronous replication and enabled with one click. When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB instance to point at the standby, which is in turn promoted to become the new primary.

The RDS read replicas provide read scaling and disaster recovery. It relieve pressure on your master node with additional read capacity. It bring data close to your application in different regions You can promote a read replica to a master for faster recovery in the event of disaster.

If you need strict read-after-write consistency (what you read is what you just wrote) then you should read from the main DB Instance. Otherwise, you should spread out the load and read from one of the read replicas. The read replicas track all of the changes made to the source DB Instance. This is an asynchronous operation. Read Replicas can sometimes be out of date with respect to the source. This phenomenon is called replication lag. Replica Lag metric in Amazon CloudWatch to allow you to see how far it has fallen behind the source DB Instance.

Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. To protect data in transit, all AWS service endpoints support TLS to create a secure HTTPS connection to make API requests. Manage secrets, API keys, and credentials with AWS Key Management Service (AWS KMS). As the team expands, with AWS Identity and Access Management (IAM), you can specify who or what can access services and resources in AWS, centrally manage fine-grained permissions, and analyze access to refine permissions across AWS. Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. Firewalls (web application, network) and DDoS protection. Thread detection, manage secret alerts, and configure security controls for individual AWS services using AWS Security, Identity & Compliance.

Amazon CloudFront is a content delivery network (CDN) service built for high performance, security, and developer convenience. It speeds up the distribution of your web content to your users, through a worldwide network of data centres called edge locations. The user request is routed to the edge location that provides the lowest latency (time delay), so that content is delivered with the best possible performance. For example, the first client sends a request in the United States, and then needs to cross half the world to Singapore to get the content, but for the second request, it is good to get the previous cache file in the data centre near the United States, which greatly reduces the distance and feedback time.

For dynamic content acceleration, you can use standard cache control headers you set on your files to identify static and dynamic content. Dynamic content is not cacheable, it proxied by CDN to the origin and back. Faster response time = Reduced DNS Time (Route 53) + Reduced Connection Time (Keep-Alive Connections & SSL Termination)+ Reduced First Byte Time (Keep-Alive Connections)+ Reduced Content Download Time (TCP/IP Optimization). It can further optimise using Latency-based Routing (LBR), run multiple stacks of the application in different Amazon EC2 regions around the world, create LBR records for each location and tag the location with geo information. Route 53 will route end users to the endpoint that provides the lowest latency.

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable applications. It can use to prevent issues by running tests and performing ng quality check. Amazon CloudWatch is a monitoring and observability service. It provides you with data and actionable insights to monitor your applications, respond to system-wide performance changes, and optimize resource utilization. Upon detection of abnormal patterns or healthh check returns error, you can trigger an alarm or actions, which could further trigger AWS Lambda, it is serverless, event-driven compute service that lets you mitigate the issue, such as restart the server or revert to the previous stable version. You can then recover from failed service instances.

For storage of objects, there are 6 choices of Amazon Simple Storage Services (Amazon S3) storage classes: S3 standard, S3 standard-IA, S3 One Zone-IA, S3 intelligent-tiering, S3 Glacier, S3 Glacier Deep Archive. The Amazon S3 Glacier storage classes are purpose-built for data archiving, providing you with the highest performance, most retrieval flexibility, and the lowest cost archive storage in the cloud.

For S3 Data Consistency, the New Objects (PUTS) has Read After Write Consistency. When you upload a new S3 object you are able to read it immediately after writing. Overwrite (PUTS) or Delete Objects got Eventual Consistency. When you overwrite or delete an object, it takes time for S3 to replicate versions to AZs. If you read it immediately, S3 may return you an old copy. You need to generally wait a few seconds before reading.

Another storage option is EBS. What is Amazon Elastic Block Storage (EBS)? Block storage volumes as a service attached to Amazon EC2 instances. It is flexible storage and performance for dynamic workloads such as stateful containers. It can be created, attached, and manage volumes through API, SDK, or AWS console. It has point-in-time snapshots and tools to automate backup and retention via policies.

gp3, General Purpose SSD are great for boot volumes, low-latency applications, and bursty databases.

  • IOPS: 3,000 - 16,000 IOPS
  • Throughput: 128 - 1,000 MiB/s
  • Latency: Single-digit ms
  • Capacity: 1 GiB to 16 TiB
  • I/O Size: Up to 256 KiB (logical merge)

io2, Block Express are ideal for critical applications and databases with sustained IOPS. It’s next-generation architecture provides 4x throughput and 4x IOPS.

  • Up to 4,000 MiB/s
  • Up to 256,000 IOPS
  • 1,000:1 IOPS to GB
  • 4x volume size up to 64 TB per volume
  • < 1-millisecond latency

st1, Throughput optimized are ideal for large-block, high-throughput sequential workloads.

  • Baseline: 40 MiB/s per TiB, up to 500 MiB/s
  • Burst: 250 MiB/s per TiB, up to 500 MiB/s
  • Capacity: 125 GiB to 16 TiB
  • I/O Size: Up to 1 MiB (logical merge)

sc1, Cold HDD are ideal for sequential throughput workloads, such as logging and backup.

  • Baseline: 12 MiB/s per TiB, up to 192 MiB/s
  • Burst: 80 MiB/s per TiB, up to 250 MiB/s
  • Capacity: 125 GiB to 16 TiB
  • I/O Size: Up to 1 MiB (logical merge)

For EBS availability, EBS volume data is replicated across multiple servers in an Availability Zone to prevent the loss of data from the failure of any single component. Protect against failures with 99.999% availability, including replication within Availablity Zone (AZs), and 99.999% durability with io2 Block Express volumes. EBS Snapshots are stored in S3, which stores data across three availability zones within a single region.

Besides, there is Amazon Elastic File System (Amazon EFS). It is serverless shared storage - no provisioning, scale capacity, connections and IOPS. It is elastic - pay only for the capacity used. Performance build-in scales with capacity. It has high durability and availability - designed for 11 9s of durability and 99.99% availability SLA.

AWS CloudFormation is a service that helps you model and set up your AWS resources so that you can spend less time managing those resources and more time focusing on your applications that run in AWS. Infrastructure as code (IaC). Consistent across accounts and regions. Dev/test environments on demand. An Amazon Machine Image (AMI) is a supported and maintained image provided by AWS that provides the information required to launch an instance.

Finally, to sum up, there are many AWS services to archive well architecture with operational excellence, security, performance efficiency, reliability and cost optimisation. There is so much to learn and let’s keep learning. Thank you very much for taking the time to read this article. Let me know if you got any questions, happy to connect

  • in podcast
  • 2 min read

Introducing Amazon Web Services (AWS)

Welcome to Continuous Improvement, the podcast where we dive deep into the world of Amazon Web Services (AWS). I'm your host, Victor Leung, an AWS community builder, here to help you navigate the vast world of cloud computing. In today's episode, we'll be discussing the fundamental aspects of AWS and how it can transform your business. So, let's get started!

So, what is AWS? Well, it's the world's most comprehensive and well-adopted cloud platform. Customers across the globe trust AWS to power their infrastructure and applications, allowing them to lower costs, become more agile, and innovate faster.

AWS provides on-demand delivery of technology services via the internet with pay-as-you-go pricing. This means that you only pay for the services you use, without any upfront costs or ongoing commitments. It's a flexible and cost-effective solution for running any type of application.

One of the key advantages of AWS is the wide range of services and features it offers. With AWS, you have access to more services and features than any other cloud provider, making it faster, easier, and more cost-effective to move your existing applications to the cloud and build new innovative solutions.

When it comes to scaling your applications, AWS has you covered with its globally deployed infrastructure. With 84 Availability Zones within 26 geographic regions worldwide and more on the way, you can easily scale your application to meet growing demand. You can choose the region closest to you and your customers, ensuring low latency and high performance.

Now, let's talk about computing power on the AWS platform. One of the key services for deploying servers is Amazon EC2, also known as Elastic Compute Cloud. With EC2, you have a wide range of instance types to choose from, each optimized for different use cases. The selection process involves considering the CPU, memory, storage, and network performance requirements of your application.

But what happens if you choose the wrong instance type? No worries! With AWS, you have the flexibility to change the instance type even after you've started an EC2 instance. Simply stop the instance, change the type, and start it again. It's that easy.

To ensure optimal performance and stability, AWS provides various CloudWatch metrics for your EC2 instances. These metrics include CPU utilization, disk operations, network traffic, and more. You can also install the CloudWatch agent to collect memory metrics and track log files.

Now, let's move on to another critical aspect of AWS: high availability and fault tolerance. AWS offers various features to ensure your applications are always up and running, even in the face of disasters. One of these features is the ability to deploy your application across multiple Availability Zones. By distributing your infrastructure, you can ensure that your application remains available even if one zone goes down.

In case of larger-scale disasters or outages, you can leverage multi-region deployments. For example, deploying your website in Singapore and setting up a backup environment in Hong Kong. By utilizing Amazon Route53, you can easily switch your domain name and redirect

  • in zh
  • 12 min read

Introducing Amazon Web Services (AWS)

Hello everyone, my name is Victor Leung and I am an AWS community builder. In this article, I would like to introduce Amazon Web Service (AWS). You may be wondering, what is AWS? It is the world's most comprehensive and well-adopted cloud platform. Customers trust AWS to power their infrastructure and applications. Organisations of every type and size are using AWS to lower costs, become more agile and innovate faster.

AWS provides on-demand delivery of technology services via the internet with pay-as-you-go pricing. You can use these services to run any type of application without upfront costs or ongoing commitments. You only pay for what you use.

Moreover, AWS gives you more services and more features within those services than any other cloud provider. This makes it faster, easier and more cost-effective to move your existing application to the cloud and to build anything you can imagine.

You can rely on AWS's globally deployed infrastructure to scale your application to meet growing demand. There are so many regions in the world, how to choose? You can start with the region closest to you and your customer. A region is a physical location in the world that consists of multiple Availability Zones. Each availability zones consist of one or more discrete data centres, each with redundant power, networking, and connectivity, housed in separate facilities. In the future, if your company expands to other regions, you can take advantage of AWS facilities as well. The AWS Cloud spans 84 Availability Zones within 26 geographic regions around the world, with announced plans for 24 more Availability Zones and 8 more AWS Regions.

As for the computing power on the cloud platform, there are several types to choose from. You can use the EC2 virtual server service to deploy your server on the platform. And there are so many types of EC2, how to choose? In fact, it is decided according to your needs, the four aspects are the CPU, memory, storage and network performance. According to the type, age, capability and size, there are certain naming conventions, such as M5d.xlarge.

Generally speaking, for the instance selection process, you can start with the best-guess instance. Then determine the constrained resources. For example, C5 instances are optimised for compute-intensive workloads. It is suited for high-performance web servers. It has cost-effective high performance at a low price per compute the ratio. Besides, for M5 instances, they are general purpose instances. It has a balance of compute, memory, and network resources. It is a good choice for many applications.

Once you started an EC2 instance, you may change the instance type as well. You can resize for over-utilized (the instance type is too small) or under-utilized (the instance type is too large) cases. This only works for EBS-backed instances. The steps are 1. Stop instance 2. Instance Settings -> Change Type 3. Start Instance. You cannot change the instance type of a Spot Instance and you cannot change the instance type if hibernation is enabled.

There are a couple of available CloudWatch metrics for your EC2 instances:

  • CPUUtilization: the percentage of allocated EC2 compute units
  • DiskReadOps: completed read operations from all instance store volumes
  • DiskWriteOps: completed write operations to all instance store volumes
  • DiskReadBytes: bytes read from all instance store volumes
  • DiskWriteBytes: bytes written to all instance store volumes
  • MetadataNoToken: number of times the instance metadata service was successfully accessed using a method
  • NetworkIn: number of bytes received by the instance
  • NetworkOut: number of bytes sent out by the instance
  • NetworkPacketsIn: number of packets received by the instance
  • NetworkPacketsOut: number of packets sent out by the instance

Besides, you can install the CloudWatch agent to collect memory metrics and log files.

When purchasing EC2, there are many options. You can start with an on-demand instance first, billed by the second, with no long-term contract. After you try it out in the future, you can choose a more cost-effective reserved instance and pay for a long-term lease of one to three years, which will save you money in the long run.

After choosing the purchase method, you can put the EC2 virtual machine into the auto-scaling group. When the demand increases, the number of EC2s can be increased at the same time, thereby increasing the computing power. When the peak period is over, such as when there is no traffic in the early morning, the number of EC2s can be automatically reduced. This automatic scaling function can be scaled independently according to different indicators, and this function is free to use.

For EC2 Load Balancing, by default, the round robin routing algorithm is used to route requests at the target group level. It is a good choice when the requests and targets are similar, or if you need to distribute requests equally among targets. You can specify the least outstanding requests routing algorithm, with consideration for capacity or utilization, to prevent over-utilization or under-utilization of targets in target groups when requests had varied processing times or targets were frequently added or removed. If you enable sticky sessions, the routing algorithm of the target group is overridden after the initial target selection.

Elastic Load Balancer (ELB) can be used to automatically assigned to one or more availability zones, and at the same time, it can check the health status of the backend servers, and increase or decrease resources horizontally according to traffic requirements. There are also several different options for load balancers. For Application Loan Balancer (ALB), which is configured according to the OSI layer 7, which is HTTP. Other load balancer can also be distributed through the fourth layer of the network OSI, using the protocols of TCP and UDP, as well as the distributor of the gateway.

Suppose your business is unlucky to encounter a large-scale accident, such as a natural disaster, an earthquake, damage to a data centre, a technical impediment, or a human error, such as an employee running a command rm -rf deletes all the data, so what should you do? Actually, there are different methods, and there are also different restoration times and origins.

As for the different methods, different costs would be charged. The higher the cost, the faster the recovery. If your business can tolerate a few hours of service interruption, a normal backup and restore scenario is fine. But if it doesn't work, and it takes a few minutes to restore service, then it's a matter of replicating an identical environment in a different region, and in a standby state.

Let me give you an example, such as deploying a website to an environment in Singapore, and deploying a backup environment in Hong Kong at the same time. Through the Route53 domain name system, the domain name is pointed to the Singapore region. When a problem occurs in the Singapore area and the entire area cannot be used, the domain name can be transferred to the Hong Kong area immediately, and normal services can be resumed. The process can be changed manually or automatically, or even distributed proportionally or on a user-by-user basis.

However, operating in two regions is relatively expensive. For generally small-scale problems, such as component failures, network issues, or sudden increases in traffic, deploying to two or more Availability Zones is fine. When a zone is unavailable, it is immediately moved to another available zone, and data can be independently replicated.

Regarding to database, you can choose RDS, which is compatible with MySQL database and can be resized. RDS is a hosted service that handles patching, backup and restore functions for you. In the future, you can also consider using Aurora. The throughput can reach about three times, but the price is also more expensive, depending on whether you want to achieve the performance of a business database.

RDS allows multi-AZ deployments, which provides enterprise-grade high availability, fault tolerance across multiple data centres with automatic failover, and synchronous replication and enabled with one click. When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB instance to point at the standby, which is in turn promoted to become the new primary.

The RDS read replicas provide read scaling and disaster recovery. It relieve pressure on your master node with additional read capacity. It bring data close to your application in different regions You can promote a read replica to a master for faster recovery in the event of disaster.

If you need strict read-after-write consistency (what you read is what you just wrote) then you should read from the main DB Instance. Otherwise, you should spread out the load and read from one of the read replicas. The read replicas track all of the changes made to the source DB Instance. This is an asynchronous operation. Read Replicas can sometimes be out of date with respect to the source. This phenomenon is called replication lag. Replica Lag metric in Amazon CloudWatch to allow you to see how far it has fallen behind the source DB Instance.

Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. To protect data in transit, all AWS service endpoints support TLS to create a secure HTTPS connection to make API requests. Manage secrets, API keys, and credentials with AWS Key Management Service (AWS KMS). As the team expands, with AWS Identity and Access Management (IAM), you can specify who or what can access services and resources in AWS, centrally manage fine-grained permissions, and analyze access to refine permissions across AWS. Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. Firewalls (web application, network) and DDoS protection. Thread detection, manage secret alerts, and configure security controls for individual AWS services using AWS Security, Identity & Compliance.

Amazon CloudFront is a content delivery network (CDN) service built for high performance, security, and developer convenience. It speeds up the distribution of your web content to your users, through a worldwide network of data centres called edge locations. The user request is routed to the edge location that provides the lowest latency (time delay), so that content is delivered with the best possible performance. For example, the first client sends a request in the United States, and then needs to cross half the world to Singapore to get the content, but for the second request, it is good to get the previous cache file in the data centre near the United States, which greatly reduces the distance and feedback time.

For dynamic content acceleration, you can use standard cache control headers you set on your files to identify static and dynamic content. Dynamic content is not cacheable, it proxied by CDN to the origin and back. Faster response time = Reduced DNS Time (Route 53) + Reduced Connection Time (Keep-Alive Connections & SSL Termination)+ Reduced First Byte Time (Keep-Alive Connections)+ Reduced Content Download Time (TCP/IP Optimization). It can further optimise using Latency-based Routing (LBR), run multiple stacks of the application in different Amazon EC2 regions around the world, create LBR records for each location and tag the location with geo information. Route 53 will route end users to the endpoint that provides the lowest latency.

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable applications. It can use to prevent issues by running tests and performing ng quality check. Amazon CloudWatch is a monitoring and observability service. It provides you with data and actionable insights to monitor your applications, respond to system-wide performance changes, and optimize resource utilization. Upon detection of abnormal patterns or healthh check returns error, you can trigger an alarm or actions, which could further trigger AWS Lambda, it is serverless, event-driven compute service that lets you mitigate the issue, such as restart the server or revert to the previous stable version. You can then recover from failed service instances.

For storage of objects, there are 6 choices of Amazon Simple Storage Services (Amazon S3) storage classes: S3 standard, S3 standard-IA, S3 One Zone-IA, S3 intelligent-tiering, S3 Glacier, S3 Glacier Deep Archive. The Amazon S3 Glacier storage classes are purpose-built for data archiving, providing you with the highest performance, most retrieval flexibility, and the lowest cost archive storage in the cloud.

For S3 Data Consistency, the New Objects (PUTS) has Read After Write Consistency. When you upload a new S3 object you are able to read it immediately after writing. Overwrite (PUTS) or Delete Objects got Eventual Consistency. When you overwrite or delete an object, it takes time for S3 to replicate versions to AZs. If you read it immediately, S3 may return you an old copy. You need to generally wait a few seconds before reading.

Another storage option is EBS. What is Amazon Elastic Block Storage (EBS)? Block storage volumes as a service attached to Amazon EC2 instances. It is flexible storage and performance for dynamic workloads such as stateful containers. It can be created, attached, and manage volumes through API, SDK, or AWS console. It has point-in-time snapshots and tools to automate backup and retention via policies.

gp3, General Purpose SSD are great for boot volumes, low-latency applications, and bursty databases.

  • IOPS: 3,000 - 16,000 IOPS
  • Throughput: 128 - 1,000 MiB/s
  • Latency: Single-digit ms
  • Capacity: 1 GiB to 16 TiB
  • I/O Size: Up to 256 KiB (logical merge)

io2, Block Express are ideal for critical applications and databases with sustained IOPS. It’s next-generation architecture provides 4x throughput and 4x IOPS.

  • Up to 4,000 MiB/s
  • Up to 256,000 IOPS
  • 1,000:1 IOPS to GB
  • 4x volume size up to 64 TB per volume
  • < 1-millisecond latency

st1, Throughput optimized are ideal for large-block, high-throughput sequential workloads.

  • Baseline: 40 MiB/s per TiB, up to 500 MiB/s
  • Burst: 250 MiB/s per TiB, up to 500 MiB/s
  • Capacity: 125 GiB to 16 TiB
  • I/O Size: Up to 1 MiB (logical merge)

sc1, Cold HDD are ideal for sequential throughput workloads, such as logging and backup.

  • Baseline: 12 MiB/s per TiB, up to 192 MiB/s
  • Burst: 80 MiB/s per TiB, up to 250 MiB/s
  • Capacity: 125 GiB to 16 TiB
  • I/O Size: Up to 1 MiB (logical merge)

For EBS availability, EBS volume data is replicated across multiple servers in an Availability Zone to prevent the loss of data from the failure of any single component. Protect against failures with 99.999% availability, including replication within Availablity Zone (AZs), and 99.999% durability with io2 Block Express volumes. EBS Snapshots are stored in S3, which stores data across three availability zones within a single region.

Besides, there is Amazon Elastic File System (Amazon EFS). It is serverless shared storage - no provisioning, scale capacity, connections and IOPS. It is elastic - pay only for the capacity used. Performance build-in scales with capacity. It has high durability and availability - designed for 11 9s of durability and 99.99% availability SLA.

AWS CloudFormation is a service that helps you model and set up your AWS resources so that you can spend less time managing those resources and more time focusing on your applications that run in AWS. Infrastructure as code (IaC). Consistent across accounts and regions. Dev/test environments on demand. An Amazon Machine Image (AMI) is a supported and maintained image provided by AWS that provides the information required to launch an instance.

Finally, to sum up, there are many AWS services to archive well architecture with operational excellence, security, performance efficiency, reliability and cost optimisation. There is so much to learn and let’s keep learning. Thank you very much for taking the time to read this article. Let me know if you got any questions, happy to connect

  • 4 min read

Understanding Kubernetes

I've been learning about Kubernetes, also known as K8s, an open-source system for automating the deployment, scaling, and management of containerized applications. Below is a summary of important concepts to understand:

Control Plane — This component makes global decisions about the cluster and consists of the following elements:

  1. ETCD: A strongly consistent, distributed key-value store that provides a reliable way to store data accessible by a distributed system or a cluster of machines.
  2. API Server: Facilitates user interaction via REST, UI, or CLI (kubectl).
  3. Scheduler: Handles resource management, assigning pods to worker nodes while complying with resource restrictions and constraints.

Data Plane — Manages resources, networking, and storage so that container workloads can run.

Namespace — Provides a logical separation of Kubernetes objects for scoping access and dividing the cluster. Every resource scope is either namespaced or cluster-wide.

Node — This can be either a virtual or a physical machine. Multiple machines or VMs constitute the backbone compute resources of a cluster. Nodes are managed by the Control Plane and host Pod objects. Their networks are configured by Service objects. Default components include:

  1. Kubelet: A Control Plane agent.
  2. Container Runtime: Responsible for scheduling Pod containers.
  3. Kube Proxy: Acts as a networking proxy within the cluster.

Pod — The most basic deployable objects in Kubernetes, resembling services or microservices. They run one or more containers with shared storage and network resources. Types of containers in a Pod include:

  1. init-container: Runs before the main container, usually to perform setup tasks.
  2. main container: Hosts the application process running in the container.
  3. sidecar: Runs alongside the main container and is loosely coupled to it.

Pods are rarely created directly; they are usually created via controller resources like Deployments, DaemonSets, Jobs, or StatefulSets.

ReplicaSet — Maintains a stable set of replica Pods running at any given time. It is generally not deployed on its own but managed by a Deployment object.

ConfigMap — Used for storing non-confidential key-value configurations. These can be used by Pods as file mounts or environment variables accessible by containers within a Pod.

Role-based Access Control (RBAC) Resources

  1. ServiceAccount: Provides an identity for all the processes running in a Pod.
  2. ClusterRole/Role: Contains rules that represent a set of permissions. These have to be associated with a ServiceAccount via a ClusterRoleBinding/RoleBinding to take effect.
  3. ClusterRoleBinding/RoleBinding: Grants the permissions defined in a ClusterRole/Role to a given ServiceAccount.

Deployment — Acts as a controller for Pods and any objects associated with them, such as ReplicaSets and ConfigMaps. It continuously reconciles the state as declared in the manifest and manages rollouts to ReplicaSets. It can be configured to execute Canary deployments, which come with garbage collection features.

HorizontalPodAutoscaler — Automatically scales workload resources like Deployments or StatefulSets based on metrics like memory and CPU usage. It can also use custom or external metrics for scaling, such as those from Prometheus.

StorageClass — Describes an abstract class of storage with properties like storage type, provider, and reclamation policies. It is used by PersistentVolume.

PersistentVolumeClaim — A user request for storage for a specific resource and privilege level.

PersistentVolume — Represents a piece of storage that can be attached to Pods and has a lifecycle independent of Pods.

Service — Serves as an abstraction for the network exposure of an application running on a set of Pods. It provides load balancing and makes Pods accessible from other Pods within the cluster.

StatefulSet — A controller for managing stateful applications. It maintains a sticky identity for each of its Pods, unlike Deployment resources, and associates each Pod with a unique instance of persistent storage. Deleting or scaling down a StatefulSet does not delete associated volumes.

Job — Suitable for applications that run tasks ending in successful completion. It deploys one or more Pods and retries until a specified number of Pods have terminated, signaling the task's conclusion.

CronJob — Similar to a Kubernetes Job but operates on a set schedule.

Ingress — Guides the cluster’s external traffic to Pods via Services. It requires an Ingress Controller (such as ingress-nginx) to fulfill the Ingress rules and can include features like external load balancing, SSL termination, and name-based virtual hosting within the cluster.

CustomResourceDefinition — Extends Kubernetes resource types by defining custom resource properties and schema.

CustomResource — An instance of a defined custom resource. CustomResources can be subscribed to by a custom controller or an operator and must have an associated CustomResourceDefinition.

These are my notes on learning about Kubernetes. If you are preparing for the CKAD, CKA, or CKS exams, feel free to reach out with any questions. Happy learning!

  • in podcast
  • 4 min read

Understanding Kubernetes

Welcome back to another episode of Continuous Improvement. I'm your host, Victor, and today we're diving into the world of Kubernetes. In this episode, we'll explore the key concepts you need to understand to navigate this powerful open-source system for automating the deployment, scaling, and management of containerized applications. So grab a cup of coffee, sit back, and let's get started.

Let's start with the Control Plane. This component plays a crucial role in making global decisions about the cluster. It consists of three fundamental elements: ETCD, API Server, and Scheduler.

ETCD acts as a distributed key-value store, providing a reliable way to store data accessible by a distributed system or a cluster of machines. It ensures strong consistency while handling data storage.

The API Server serves as the interface through which users interact with the cluster. Whether it's through REST, a user interface, or the command-line tool kubectl, the API Server facilitates seamless communication and management.

The Scheduler handles resource management, ensuring that Kubernetes efficiently assigns pods to worker nodes while adhering to resource restrictions and constraints.

Moving on to the Data Plane, this is where the resources, networking, and storage management come into play to enable container workloads to run smoothly.

In Kubernetes, a Namespace provides a logical separation of objects within the cluster. It scopes access and divides the cluster, allowing for better organization and management.

Nodes, whether they are virtual or physical machines, form the backbone compute resources of a cluster. They are managed by the Control Plane and host Pod objects. Kubelet is a critical component that acts as a Control Plane agent on each node, while the Container Runtime schedules and manages the Pod containers. Kube Proxy acts as a networking proxy within the cluster, ensuring smooth communication between Pods.

Now, let's talk about Pods. These are the basic deployable objects in Kubernetes and can be seen as services or microservices. Pods can run one or more containers, sharing storage and network resources. Within a Pod, you may have an init-container to perform setup tasks before the main container starts, the main container hosting the application process, and even a sidecar container loosely coupled to the main container.

It's important to note that Pods are typically created via controller resources like Deployments, DaemonSets, Jobs, or StatefulSets. A ReplicaSet, for example, ensures a stable set of replica Pods running at any given time.

ConfigMaps come in handy when storing non-confidential key-value configurations. These can be used by Pods as file mounts or environment variables accessible by the containers within a Pod.

Now let's explore the Role-based Access Control (RBAC) Resources. A ServiceAccount provides an identity for all processes running within a Pod. ClusterRole and Role contain sets of permissions, while ClusterRoleBinding and RoleBinding grant those permissions to a specific ServiceAccount.

Deployments act as controllers for Pods and associated objects like ReplicaSets and ConfigMaps. They continuously monitor and reconcile the state as declared in the manifest, making rollouts to ReplicaSets seamless. Canary deployments, with garbage collection features, can also be executed.

The HorizontalPodAutoscaler automates the scaling of workload resources based on metrics like memory and CPU usage. It can also utilize custom or external metrics for scaling, such as those provided by Prometheus.

StorageClass describes an abstract class of storage with properties like storage type, provider, and reclamation policies. It is utilized by PersistentVolume, which represents storage that can be attached to Pods and has a lifecycle independent of the Pods themselves.

Moving on to Services, they serve as abstractions for network exposure. They provide load balancing and make Pods accessible from other Pods within the cluster.

For stateful applications, there's the StatefulSet controller. Unlike Deployment resources, it maintains a sticky identity for each Pod and associates each Pod with a unique instance of persistent storage. Deleting or scaling down a StatefulSet does not delete associated volumes.

A Job is ideal for applications that run tasks ending in successful completion. It deploys one or more Pods and retries until a specified number of Pods have terminated, signaling the task's conclusion. And for scheduled tasks, we have CronJobs, which operate on a set schedule.

To guide external traffic to Pods via Services, we have Ingress. Ingress requires an Ingress Controller, such as ingress-nginx, to fulfill Ingress rules. It can handle external load balancing, SSL termination, and name-based virtual hosting within the cluster.

If you're looking to extend Kubernetes resource types, CustomResourceDefinition allows you to define custom resource properties and schemas. These can be subscribed to by custom controllers or operators, and each CustomResource must have an associated CustomResourceDefinition.

And there you have it — a whirlwind tour of important Kubernetes concepts. Whether you're preparing for the CKAD, CKA, or CKS exams or simply looking to enhance your Kubernetes knowledge, I hope this episode has given you valuable insights.

Don't forget, if you have any questions or thoughts to share, feel free to reach out. Until next time, keep learning and embracing continuous improvement.

Thank you for tuning in to this episode of Continuous Improvement. If you enjoyed this content, don't forget to subscribe and leave us a review. And remember, your feedback helps us grow and improve. Stay curious and never stop learning. See you in the next episode!

  • in zh
  • 2 min read

了解 Kubernetes

我一直在學習 Kubernetes，也被稱為 K8s，這是一個用於自動化部署，擴展和管理容器化應用程序的開源系統。以下是理解的重要概念摘要：

控制平面 - 這個組件對集群做出全局決策，包括以下元素：

  1. ETCD：一個強一致性，分佈式鍵值存儲，提供了一種由分佈式系統或機器群組訪問數據的可靠方法。
  2. API 服務器：通過 REST，UI 或 CLI（kubectl）促進用戶互動。
  3. 調度器：處理資源管理，將工作節點分配給工作節點，同時遵守資源限制和約束。

數據平面 - 管理資源，網絡和存儲，以便可以運行容器工作負載。

命名空間 - 在 Kubernetes 物件範圍訪問和劃分集群提供邏輯分離。每個資源範疇都是命名空間或集群範圍的。

節點 - 這可以是虛擬機或實體機。多台機器或 VM 構成集群的主體計算資源。節點由控制平面管理，並託管 Pod 物件。他們的網絡由服務物件配置。默認組件包括：

  1. Kubelet：控制平面代理。
  2. 容器運行時：負責調度 Pod 容器。
  3. Kube Proxy：在集群內擔任網絡代理。

Pod - Kubernetes 中最基本的可部署物件，類似於服務或微服務。他們運行一個或多個具有共享存儲和網絡資源的容器。一個 Pod 中的容器類型包括：

  1. init-container：主要容器運行之前運行，通常用於執行設置任務。
  2. 主容器：托管在容器中運行的應用程序進程。
  3. sidecar：與主容器一起運行，與之鬆散耦合。

Pod 很少直接創建，通常通過控制器資源，如部署，DaemonSets，工作或 StatefulSets 創建。

ReplicaSet - 在任何給定的時間維持一組穩定的副本 Pod 運行。它通常不會單獨部署，而是由部署物件管理。

ConfigMap - 用於存儲非機密鍵值配置。Pod 可以將其用作文件掛載或者環境變量，由 Pod 中的容器訪問。

基於角色的訪問控制 (RBAC) 資源

  1. 服務賬戶：為 Pod 中運行的所有進程提供身份證明。
  2. 集群角色/角色：包含代表一組權限的規則。這些必須通過 ClusterRoleBinding 或 RoleBinding 與服務賬戶關聯以生效。
  3. ClusterRoleBinding / RoleBinding：授予在 ClusterRole / Role 中定義的權限給指定的 ServiceAccount。

部署 - 作為 Pod 和與他們相關的任何物件（如 ReplicaSets 和 ConfigMaps）的控制器。它不斷地調解在清單中聲明的狀態，並管理捲出到 ReplicaSets。可以配置為執行 Canary 部署，這帶有垃圾回收功能。

HorizontalPodAutoscaler - 根據內存和 CPU 使用情況等指標自動調整工作負載資源，如部署或 StatefulSets。它還可以使用像 Prometheus 這樣的自定義或外部指標進行縮放。

StorageClass - 描述具有存儲類型，提供商和回收政策等屬性的抽象存儲類。由 PersistentVolume 使用。

持久性存儲磁卷索賠 - 對特定資源和權限級別的存儲的用戶請求。

PersistentVolume - 代表一塊可以附加到 Pod 的存儲，並有一個獨立於 Pod 的生命週期。

服務 - 作為在一組 Pod 上運行的應用程序的網絡暴露的抽像。它提供負載均衡並使得一個集群內的 Pod 可以訪問其他 Pod。

StatefulSet - 用於管理含有狀態的應用程式的控制器。它為其每個 Pod 保持粘性身份，與部署資源不同，並將每個 Pod 與一個獨特的持久存儲實例相關聯。刪除或縮小 StatefulSet 不會刪除關聯的磁卷。

工作 - 適用於運行結束在成功完成的任務的應用程序。它部署一個或多個 Pod，並重試，直到指定數量的 Pod 已經終止，表示任務的結束。

CronJob - 類似於 Kubernetes 工作，但是按照設置的計劃運行。

Ingress - 通過服務將集群的外部流量引導到 Pod。它需要一個 Ingress 控制器（比如 ingress-nginx）來實現 Ingress 規則，並可以包括像外部負載均衡，SSL 終止和在集群內的基於名稱的虛擬託管等功能。

CustomResourceDefinition - 通過定義自定義資源屬性和模式來擴展 Kubernetes 資源類型。

CustomResource - 自定義資源的實例。CustomResources 可以被自定義控制器或運營商訂閱，並且必須有一個相關的 CustomResourceDefinition。

這些是我在學習 Kubernetes 的筆記。如果你正在準備 CKAD，CKA，或 CKS 考試，隨時與我提出任何問題。開心學習！

  • 3 min read

Understanding Service Mesh and Istio

As a software developer, I sometimes find infrastructure networking quite confusing. In this article, I will delve deeper to understand service mesh and Istio. A service mesh is a dedicated infrastructure layer responsible for handling service-to-service communication. It ensures the reliable delivery of requests through the complex topology of services that comprise a modern, cloud-native application.

In practice, a service mesh is usually implemented as an array of lightweight network proxies deployed alongside the application code, without requiring the application to be aware of them. Contrary to its name, a service mesh is not actually a mesh of services but rather a mesh of proxies that abstract away the network layer. The service mesh primarily fulfills three functions: flow control, security, and observability.

The control plane manages the flow of configuration data from a central unit to the proxies that make up the mesh. The data plane, on the other hand, manages the flow of application data between microservices in the mesh, facilitated by the sidecar proxy.

One commonly used service mesh is Istio. Born out of a partnership between Google, IBM, and Lyft (Envoy proxy), Istio is an open-source project that provides a transparent infrastructure layer for managing inter-service communication on Kubernetes. It hijacks network traffic bound for a pod and proxies it through an intelligent Layer 7 proxy (Envoy), mounted as a sidecar to the main container. Istio applies advanced routing and policy rules, enhances security and resiliency, and uses mutual TLS for communication between peers.

Istio offers immediate advantages in the core functions of a service mesh: flow control, security, and observability. However, it does introduce complexities, such as operational overhead and a slight latency at the link level. It also requires platform adaptation and consumes extra resources like memory and CPU.

The Istio control plane, known as istiod, performs various functions: service discovery, proxy configuration, certificate management, and more. In older versions of Istio, these functions were divided among separate deployments but have since been consolidated into istiod.

Istio's data plane consists of Envoy proxy instances that communicate with the Istio control plane. Once configured and synchronized, these proxies manage all inbound and outbound network traffic to pods, applying advanced Layer 7 routing and policy rules. The configuration is achieved through the control plane's Rules-Based API, which then compiles it into Envoy-specific settings.

To be entirely transparent to application developers, Istio reroutes all traffic to Envoy by manipulating the IP tables of all pods in the service mesh. Traffic hijacking is accomplished through either an init container (istio-init) or Istio's Container Networking Interface (CNI) plugin.

Istio's flow control capabilities can be divided into three categories: request routing, resilience, and debugging. It exposes a Rule-Based API that allows users to configure traffic management within the mesh. Traffic policies applied to a host service are based on various matching conditions, such as load balancing strategies, connection pool settings, and outlier detection.

Istio also offers a Security API to configure policies at varying levels of granularity. It supports three modes of TLS communication: DISABLE, PERMISSIVE, and STRICT. By looking at Istio request metrics, you can determine whether a request was proxied over mTLS.

In summary, this article serves as a brief deep dive into service mesh and Istio. There's still much more to explore. Thank you for reading this article, and let's continue learning!

  • in podcast
  • 3 min read

Understanding Service Mesh and Istio

Hello, and welcome to Continuous Improvement, the podcast where we dive deep into various topics related to software development and infrastructure. I'm your host, Victor, and in today's episode, we are going to explore the fascinating world of service mesh and specifically focus on Istio. So, whether you're a software developer or just curious about how networks in the cloud work, this episode is for you!

As a software developer, I sometimes find infrastructure networking quite confusing. But fear not, because today we'll be unraveling the mysteries of service mesh and shedding light on Istio.

So, what exactly is a service mesh? Well, to put it simply, a service mesh is a dedicated infrastructure layer responsible for handling service-to-service communication. It ensures reliable delivery of requests through the complex topology of services in a cloud-native application.

In practice, a service mesh is usually implemented as a collection of lightweight network proxies deployed alongside the application code. The beauty of it is that the application doesn't even need to be aware of these proxies. Contrary to its name, a service mesh is not a mesh of services, but rather a mesh of proxies that abstract away the network layer.

Now, a service mesh fulfills three primary functions: flow control, security, and observability. The control plane manages the flow of configuration data from a central unit to the proxies that make up the mesh. Meanwhile, the data plane handles the flow of application data between microservices, facilitated by the sidecar proxy.

One popular service mesh that you may have heard of is Istio. Istio is an open-source project born out of a collaboration between Google, IBM, and Lyft's Envoy proxy. It provides a transparent infrastructure layer for managing inter-service communication on Kubernetes.

So how does Istio work? It intercepts network traffic bound for a pod and proxies it through an intelligent Layer 7 proxy called Envoy, which is mounted as a sidecar to the main container. Istio then applies advanced routing and policy rules to enhance security, resiliency, and observability. It even uses mutual TLS for communication between peers.

Using Istio offers immediate advantages in the three core functions of a service mesh. However, it's important to note that there are complexities involved, such as operational overhead and a slight latency at the link level. Istio also requires platform adaptation and consumes additional resources like memory and CPU.

Let's take a closer look at the components of Istio. The control plane, known as istiod, handles functions like service discovery, proxy configuration, certificate management, and more. In older versions of Istio, these functions were spread out among separate deployments, but they have since been consolidated into istiod.

The data plane of Istio consists of Envoy proxy instances that communicate with the Istio control plane. Once configured and synchronized, these proxies manage all inbound and outbound network traffic to pods by applying advanced Layer 7 routing and policy rules. The configuration is achieved through the control plane's Rules-Based API, which then compiles it into Envoy-specific settings.

To be entirely transparent to application developers, Istio reroutes all traffic to Envoy by manipulating the IP tables of all pods in the service mesh. Traffic hijacking is achieved through either an init container called istio-init or Istio's Container Networking Interface (CNI) plugin.

In addition to its core functionalities, Istio also offers a Security API that allows you to configure policies at different levels of granularity. It supports various modes of TLS communication, such as DISABLE, PERMISSIVE, and STRICT. By examining Istio request metrics, you can determine whether a request was proxied over mTLS.

In conclusion, service mesh and Istio are fascinating technologies that provide a dedicated infrastructure layer to manage inter-service communication. Although they bring immediate advantages in terms of flow control, security, and observability, they also introduce complexities and require platform adaptation.

I hope this episode helped shed some light on service mesh and Istio. Remember, learning is a continuous process, and there's always more to explore. Thank you for tuning in to Continuous Improvement. I'm Victor, and until next time, keep improving!

  • in zh
  • 1 min read

理解服務網格和 Istio

作為一名軟體開發人員，我有時會覺得基礎設施網路相當混淆。在這篇文章中，我將更深入地理解服務網格和 Istio。服務網格是一個專門負責處理服務與服務通信的基礎設施層。它確保請求通過組成現代雲原生應用程序的複雜服務拓撲的可靠傳遞。

實踐中，服務網格通常以輕量級網路代理的陣列形式實現，並與應用程序代碼一起部署，而無需應用程序知道它們。與其名稱相反，服務網格並非實際上的服務網格，而是抽象出網路層的代理網格。服務網格主要執行三個功能：流量控制，安全性和可觀察性。

控制平面將配置數據的流動從中央單位管理到組成網格的代理。而資料平面則管理由 sidecar 代理輔助的網格中微服務的應用數據流動。

一個常用的服務網格就是 Istio。Istio 是由 Google、IBM 和 Lyft（Envoy 代理）合作開發的開源項目，提供一個為在 Kubernetes 上管理服務間通信的透明基礎設施層。它攔截網路流量並將其代理到掛載為 main 容器的側車的智能 Layer 7 代理。 Istio 應用高級路由和策略規則，增強安全性和彈性，並在對等體間通信時使用互相認證的 TLS。

Istio 在服務網格的核心功能上提供了即時優勢：流量控制，安全性和可觀察性。然而，它確實引入了一些複雜性，例如運營開銷和鏈路級別的輕微延遲。它還需要平台適應性並消耗額外的資源，如內存和 CPU。

Istio 的控制平面，稱為 istiod，執行多種功能：服務發現，代理配置，證書管理等等。在 Istio 的舊版本中，這些功能被劃分為獨立的部署，但現已統一在 istiod 中。

Istio 的資料平面由與 Istio 控制平面通信的 Envoy 代理實例組成。一旦配置和同步，這些代理就能管理所有進出網格的網路流量，並應用高級 Layer 7 的路由和策略規則。其配置是通過控制平面的基於規則的 API 實現的，然後再編譯成 Envoy 專用的設定。

為使應用程序開發人員完全不知道 Istio 的存在，Istio 通過操縱 IP 表操縱全網格中所有 pod 的流量的傳輸到 Envoy。流量劫持通過 init 容器 (istio-init) 或 Istio 的 Container Networking Interface (CNI) 插件來實現。

Istio 的流量控制功能可以劃分為三類：請求路由、韌性和偵錯。它提供了一個基於規則的 API，允許用戶配置網格內的流量管理。應用于主機服務的流量策略基於各種匹配條件，例如負載均衡策略、連接池設置以及異常檢測。

Istio 還提供了一種 Security API，以在各種細粒度級別配置策略。它支援三種模式的 TLS 通訊：DISABLE，PERMISSIVE和 STRICT。通過查看 Istio 請求指標，可以瞭解是否通過 mTLS 代理進行請求。

總結，這篇文章是對服務網格和 Istio 的簡短深入瞭解。還有更多需要探索的。感謝您閱讀此篇文章，讓我們繼續學習！

  • 3 min read

My Career Story

I've been interested in technology since university, where I took an elective in Java programming. I fell in love with the subject and knew I wanted to make it my career. After earning a bachelor's degree in Chemistry, I worked as a marketing manager in the tourism industry. There, I met many marketers with business acumen but lacking technical skills, particularly in SEO and website building. This inspired me to switch careers and become a software engineer at an Australian consulting firm, where I gained advanced front-end development skills. Outside of work, I pursued a part-time degree in computer science, which proved to be incredibly rewarding.

One significant challenge during my software consulting role at Accenture was adhering to tight timelines. I managed a large customer-based mobile app for an airline. Given the numerous feature requirements, I adopted an agile approach to continually deliver value. Occasionally, I had to negotiate with the product owner to overcome project blockers. Ultimately, we launched the mobile app successfully, meeting business requirements and earning customer satisfaction. This experience taught me that technology alone can't solve all business problems. Hence, I enrolled in a part-time MBA program to better understand the intersection of business and technology.

While consulting for EY in the banking sector, we faced a setback involving the choice of a cloud platform. We initially developed a banking wallet product using Amazon Web Services (AWS), assuming it met all requirements. However, just before going live, we realized that the AWS data center in Hong Kong was delayed. Due to regulatory requirements, we had to migrate to Microsoft Azure. I advised and executed the new technical architecture to ensure compliance.

At Dynatrace, I was part of the post-sales team, focusing on software monitoring products. One memorable project involved a new client at Huawei who wanted to integrate our product into their cloud platform. Working onsite in Shenzhen, I faced a demanding work culture and a 9 am to 9 pm, six-day work week. Despite this, the project launched successfully, thanks in part to my proactive responses to client queries.

As a technical lead at HSBC, I oversaw the development of an online payment solution for merchants in Malaysia. I noticed that the team was fragmented, with individuals focusing on either the back end or the front end, but no one looking at the overall user experience. Compounding the issue were office politics, which hindered our progress. To overcome these challenges, I engaged with customers to understand their needs and consulted Splunk logs for error data. Taking ownership of the results, I delegated tasks effectively, which led to a rise in transaction success rates from 40% to 70%.

Currently, as a client engineering manager at Thought Machine, I recently assisted a colleague in pre-sales who had to present to one of Taiwan's largest banks. With only a week to prepare and my colleague not being fluent in Mandarin, I translated and presented the slides. It was a challenging task, but the presentation was well-received.

In my present role, I also conduct training sessions for new team members, clients, and partners in Vietnam. Although English is our second language, I make sure to speak clearly and use various phrases to get my points across.

Outside of work, I have a passion for continuous learning. I am certified in various cloud platforms and have Scrum certifications for project management. I also enjoy honing my communication and public speaking skills through Toastmasters clubs.

In summary, I thrive on exploring new technologies and finding solutions at the intersection of business and tech. I love collaborating with customers, partners, and teams to create robust architectures and demonstrations based on customer needs. Feel free to connect with me: https://www.linkedin.com/in/victorleungtw.