Tech With Htunn
  • Blog Content
  • ๐Ÿค–Artificial Intelligence
    • ๐Ÿง Building an Intelligent Agent with Local LLMs and Azure OpenAI
    • ๐Ÿ“ŠRevolutionizing IoT Monitoring: My Personal Journey with LLM-Powered Observability
  • ๐Ÿ“˜Core Concepts
    • ๐Ÿ”„Understanding DevSecOps
    • โฌ…๏ธShifting Left in DevSecOps
    • ๐Ÿ“ฆUnderstanding Containerization
    • โš™๏ธWhat is Site Reliability Engineering?
    • โฑ๏ธUnderstanding Toil in SRE
    • ๐Ÿ”What is Identity and Access Management?
    • ๐Ÿ“ŠMicrosoft Graph API: An Overview
    • ๐Ÿ”„Understanding Identity Brokers
  • ๐Ÿ”ŽSecurity Testing
    • ๐Ÿ”SAST vs DAST: Understanding the Differences
    • ๐ŸงฉSoftware Composition Analysis (SCA)
    • ๐Ÿ“‹Software Bill of Materials (SBOM)
    • ๐ŸงชDependency Scanning in DevSecOps
    • ๐ŸณContainer Scanning in DevSecOps
  • ๐Ÿ”„CI/CD Pipeline
    • ๐Ÿ”My Journey with Continuous Integration in DevOps
    • ๐Ÿš€My Journey with Continuous Delivery and Deployment in DevOps
  • ๐ŸงฎFundamentals
    • ๐Ÿ’พWhat is Data Engineering?
    • ๐Ÿ”„Understanding DataOps
    • ๐Ÿ‘ทThe Role of a Cloud Architect
    • ๐Ÿ›๏ธCloud Native Architecture
    • ๐Ÿ’ปCloud Native Applications
  • ๐Ÿ›๏ธArchitecture & Patterns
    • ๐Ÿ…Medallion Architecture in Data Engineering
    • ๐Ÿ”„ETL vs ELT Pipeline: Understanding the Differences
  • ๐Ÿ”’Authentication & Authorization
    • ๐Ÿ”‘OAuth 2.0 vs OIDC: Key Differences
    • ๐Ÿ”Understanding PKCE in OAuth 2.0
    • ๐Ÿ”„Service Provider vs Identity Provider Initiated SAML Flows
  • ๐Ÿ“‹Provisioning Standards
    • ๐Ÿ“ŠSCIM in Identity and Access Management
    • ๐Ÿ“กUnderstanding SCIM Streaming
  • ๐Ÿ—๏ธDesign Patterns
    • โšกEvent-Driven Architecture
    • ๐Ÿ”’Web Application Firewalls
  • ๐Ÿ“ŠReliability Metrics
    • ๐Ÿ’ฐError Budgets in SRE
    • ๐Ÿ“SLA vs SLO vs SLI: Understanding the Differences
    • โฑ๏ธMean Time to Recovery (MTTR)
Powered by GitBook
On this page
  • My Definition of Cloud-Native Architecture
  • The Pillars That Changed How I Build Software
  • My Python Microservices Journey with AWS Lambda
  • Why I Chose Python for Microservices
  • Setting Up a Basic Python Microservice for AWS Lambda
  • How I Deploy Microservices with AWS SAM
  • Lessons I've Learned Building Cloud-Native Systems
  • Why This Approach Works For Me
  1. Fundamentals

Cloud Native Architecture

After spending years building traditional monolithic applications, my transition to cloud-native architecture was both challenging and incredibly rewarding. Let me share what I've learned and how Python microservices on AWS Lambda transformed our team's approach to software development.

My Definition of Cloud-Native Architecture

Cloud-native architecture isn't just about moving applications to the cloudโ€”it's about embracing a fundamentally different mindset. It's designing systems that are born in the cloud and take full advantage of cloud capabilities. Throughout my career, I've found that truly cloud-native systems help teams deliver value faster while maintaining flexibility to adapt to changing requirements.

The Pillars That Changed How I Build Software

When I first started exploring cloud-native architecture, these five principles revolutionized my approach:

  1. Microservices: Breaking down my monolithic applications into smaller, focused services was challenging at first but ultimately liberating. Each service could evolve independently.

  2. Containerization: Using Docker to package microservices ensured consistency across environments. I no longer heard "but it works on my machine!"

  3. DevOps Automation: Adopting practices that bridge development and operations reduced our deployment friction dramatically.

  4. CI/CD Pipelines: Automating our build, test, and deployment processes allowed us to release reliably multiple times per day.

  5. Serverless Computing: This was the game-changer for meโ€”running code without managing servers helped me focus on business logic rather than infrastructure.

My Python Microservices Journey with AWS Lambda

Let me share a real example from my experience building a content management system with Python microservices on AWS Lambda.

Why I Chose Python for Microservices

Python's simplicity and robust ecosystem made it perfect for building focused microservices. Libraries like Flask, Boto3, and Requests allowed me to create powerful APIs with minimal code.

Setting Up a Basic Python Microservice for AWS Lambda

Here's how I structure a typical Python microservice for AWS Lambda:

# app.py - A simple article management microservice
import json
import boto3
import uuid
from datetime import datetime

# Initialize DynamoDB client
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Articles')

def lambda_handler(event, context):
    """Main Lambda function handler for article management API"""
    
    http_method = event['httpMethod']
    path = event['path']
    
    # Route requests based on HTTP method and path
    if http_method == 'POST' and path == '/articles':
        return create_article(event)
    elif http_method == 'GET' and '/articles/' in path:
        article_id = path.split('/')[-1]
        return get_article(article_id)
    else:
        return {
            'statusCode': 404,
            'body': json.dumps({'error': 'Not found'})
        }

def create_article(event):
    """Create a new article in the database"""
    try:
        body = json.loads(event['body'])
        
        # Data validation
        if not all(key in body for key in ['title', 'content', 'author']):
            return {
                'statusCode': 400,
                'body': json.dumps({'error': 'Missing required fields'})
            }
        
        # Create article item
        article = {
            'id': str(uuid.uuid4()),
            'title': body['title'],
            'content': body['content'],
            'author': body['author'],
            'created_at': datetime.now().isoformat(),
            'status': 'published'
        }
        
        # Save to DynamoDB
        table.put_item(Item=article)
        
        return {
            'statusCode': 201,
            'body': json.dumps({'message': 'Article created', 'id': article['id']})
        }
    except Exception as e:
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

def get_article(article_id):
    """Retrieve an article by ID"""
    try:
        response = table.get_item(Key={'id': article_id})
        
        if 'Item' in response:
            return {
                'statusCode': 200,
                'body': json.dumps(response['Item'])
            }
        else:
            return {
                'statusCode': 404,
                'body': json.dumps({'error': 'Article not found'})
            }
    except Exception as e:
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

How I Deploy Microservices with AWS SAM

The AWS Serverless Application Model (SAM) simplified my deployment process. Here's a typical template.yaml I use:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Article Management Microservice

Resources:
  ArticleFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./
      Handler: app.lambda_handler
      Runtime: python3.9
      Timeout: 10
      MemorySize: 256
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref ArticlesTable
      Events:
        CreateArticle:
          Type: Api
          Properties:
            Path: /articles
            Method: post
        GetArticle:
          Type: Api
          Properties:
            Path: /articles/{id}
            Method: get

  ArticlesTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: Articles
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH

Lessons I've Learned Building Cloud-Native Systems

Throughout my journey with Python microservices and AWS Lambda, I've discovered:

  1. Start Simple: My first microservices were too granular. I've learned to start with larger functional boundaries and refactor as needed.

  2. Embrace Event-Driven Design: Using AWS services like EventBridge to communicate between services has made my architectures more resilient.

  3. Cold Starts Matter: Lambda functions have initialization times (cold starts). For latency-sensitive operations, I either keep functions warm or consider containers.

  4. Infrastructure as Code is Essential: Using AWS SAM or Terraform to define infrastructure ensures consistency and enables version control of my architecture.

  5. Monitoring is Different: With distributed systems, I've had to adopt new approaches to monitoring and tracing with tools like AWS X-Ray.

Why This Approach Works For Me

Cloud-native architecture with Python microservices on AWS Lambda has allowed my team to:

  • Focus on writing business logic, not maintaining servers

  • Scale automatically with demand without overprovisioning

  • Develop and deploy features independently

  • Pay only for actual compute time used

  • Recover quickly from failures with minimal impact

If you're considering moving to cloud-native architecture, start smallโ€”decompose one part of your application into a serverless microservice and learn from the experience. The journey is worth it!

PreviousThe Role of a Cloud ArchitectNextCloud Native Applications

Last updated 22 hours ago

๐Ÿงฎ
๐Ÿ›๏ธ