christova

Below is a diagram showing the evolution of architecture and processes since the 1980s. Organizations can build and run scalable applications on public, private, and hybrid clouds using cloud native technologies. This means the applications are designed to leverage cloud features, so they are resilient to load and easy to scale. Cloud native includes 4 aspects:

1. Development process This has progressed from waterfall to agile to DevOps.

2. Application Architecture The architecture has gone from monolithic to microservices. Each service is designed to be small, adaptive to the limited resources in cloud containers.

3. Deployment & packaging The applications used to be deployed on physical servers. Then around 2000, the applications that were not sensitive to latency were usually deployed on virtual servers. With cloud native applications, they are packaged into docker images and deployed in containers.

4. Application infrastructure The applications are massively deployed on cloud infrastructure instead of self-hosted servers.

#CloudNative

#algorithm #domination

Choreography is like having a choreographer set all the rules. Then the dancers on stage (the microservices) interact according to them. Service choreography describes this exchange of messages and the rules by which the microservices interact.

Orchestration is different. The orchestrator acts as a center of authority. It is responsible for invoking and combining the services. It describes the interactions between all the participating services. It is just like a conductor leading the musicians in a musical symphony. The orchestration pattern also includes the transaction management among different services.

The benefits of orchestration:

1. Reliability – orchestration has built-in transaction management and error handling, while choreography is point-to-point communications and the fault tolerance scenarios are much more complicated.

2. Scalability – when adding a new service into orchestration, only the orchestrator needs to modify the interaction rules, while in choreography all the interacting services need to be modified.

Some limitations of orchestration:

1. Performance – all the services talk via a centralized orchestrator, so latency is higher than it is with choreography. Also, the throughput is bound to the capacity of the orchestrator.

2. Single point of failure – if the orchestrator goes down, no services can talk to each other. To mitigate this, the orchestrator must be highly available.

Real-world use case: Netflix Conductor is a microservice orchestrator and you can read more details on the orchestrator design.

Think of JWT like a movie ticket for your app. It proves who you are and what you're allowed to do.

Here's how it works:

- 1. Login: You log in to an app. - 2. JWT Creation: The server creates a token with your info (like user ID) and signs it with a secret. - 3. Token Use: The token is sent to your app, and every time you make a request, it’s sent back to prove it’s you. - 4. Server Verifies: The server checks the token's signature to confirm it hasn’t been tampered with.

Why use it?

JWT is self-contained, secure, and doesn’t require the server to store session data. Just make sure to avoid sensitive info in the token and always use HTTPS!

#JSONWebToken #WebToken #JWT

#kafka #polling #webhook

Docker's architecture comprises three main components:

Docker Client

This is the interface through which users interact. It communicates with the Docker daemon.

Docker Host

Here, the Docker daemon listens for Docker API requests and manages various Docker objects, including images, containers, networks, and volumes.

Docker Registry

This is where Docker images are stored. Docker Hub, for instance, is a widely-used public registry.

#docker

#API #SDK

Polling Vs Webhooks

Polling

Polling involves repeatedly checking the external service or endpoint at fixed intervals to retrieve updated information.

It’s like constantly asking, “Do you have something new for me?” even where there might not be any update.

This approach is resource-intensive and inefficient.

Also, you get updates only when you ask for it, thereby missing any real-time information.

However, developers have more control over when and how the data is fetched.

Webhooks

Webhooks are like having a built-in notification system.

You don’t continuously ask for information. Instead you create an endpoint in your application server and provide it as a callback to the external service (such as a payment processor or a shipping vendor)

Every time something interesting happens, the external service calls the endpoint and provides the information.

This makes webhooks ideal for dealing with real-time updates because data is pushed to your application as soon as it’s available.

So, when to use Polling or Webhook? Polling is a solid option when there is some infrastructural limitation that prevents the use of webhooks. Also, with webhooks there is a risk of missed notifications due to network issues, hence proper retry mechanisms are needed.

Webhooks are recommended for applications that need instant data delivery. Also, webhooks are efficient in terms of resource utilization especially in high throughput environments.

#polling #webhooks

The mobile app release process differs from conventional methods. This illustration simplifies the journey to help you understand.

Typical Stages in a Mobile App Release Process:

1. Registration & Development (iOS & Android):

- Enroll in Apple's Developer Program and Google Play Console as iOS and Android developer

- Code using platform-specific tools: Swift/Obj-C for iOS, and Java/Kotlin for Android

2. Build & Test (iOS & Android):

Compile the app's binary, run extensive tests on both platforms to ensure functionality and performance. Create a release candidate build.

3. QA:

- Internally test the app for issue identification (dogfooding)

- Beta test with external users to collect feedback

- Conduct regression testing to maintain feature stability

4. Internal Approvals:

- Obtain approval from stakeholders and key team members.

- Comply with app store guidelines and industry regulations

- Obtain security approvals to safeguard user data and privacy

5. App Store Optimization (ASO):

- Optimize metadata, including titles, descriptions, and keywords, for better search visibility

- Design captivating screenshots and icons to entice users

- Prepare engaging release notes to inform users about new features and updates

6. App Submission To Store:

- Submit the iOS app via App Store Connect following Apple's guidelines

- Submit the Android app via Google Play Console, adhering to Google's policies

- Both platforms may request issues resolution for approval

7. Release:

- Upon approval, set a release date to coordinate the launch on both iOS and Android platforms

Over to you: What's the most challenging phase you've encountered in the mobile app release process?

#mobile #MobileDevelopment #android #iOS #release

#MultiThreading #threads #DesignPatterns