Last week we explored the differences between monolithic and microservices architecture.

It opened up one very important point:

Solutions should be designed based on what the system needs right now; as the system evolves, so should your solution.

This is why it’s very common for systems to start off as a monolith, and then break out into microservices in the future.

To wrap up this discussion, let's look at the best practices that'll make going from monolithic to microservices a smoother process:

Start by listing the different capabilities and business domains in your system.

Once that’s done, identify the boundaries of each.

This will help guide the transition and ensure your microservices architecture stays loosely coupled.

Before you start breaking up your monolith, make sure you have planned out your strategy from start to finish.

Incorporate DevOps practices to ensure development and deployment are streamlined, and the system stays resilient.

Start with the lowest-hanging fruit.

This will help you quickly test and refine your approach with less complex services.

Which will save you from a lot of headaches once you tackle those large and heavily intertwined services.

With a change as big as this one, you can expect something to go wrong.

As you’re splitting out the services, make sure you’re adding mechanisms that help the system handle failure.

Such as redundancy, rate limiting, and health checks.

It’s always a good idea to test your changes.

But when your changes are so far-reaching, it’s almost impossible to test for every scenario and edge case.

This is why logs and alerts are so important.

It helps you quickly identify, debug, and fix problems.

Sometimes, before your end-users even notice it!

———

Large system changes can be very daunting.

But you can save yourself from a lot of headaches by learning from others; which is where best practices can come in handy.

Components of a URL

SQL Number Functions

See the full post: Click here

Symmetric-key cryptography: a shared key is used for both encryption and decryption.
- Anyone with access to the key can decrypt the data which is why keys should be shared over a secure connection.
- Ideal for when encryption and decryption should be quick. Eg; encrypting bulk amounts of data.
Asymmetric-key cryptography: two different keys are used for encryption and decryption; a public key and a private key.
- Widely used where communication is done over an insecure medium such as web browsing or emailing.
Hash functions: a function is used to convert an input (text) into a unique hash that is near impossible to reverse and retrieve the original text.
- They’re used heavily in security & data retrieval in conjunction with other methods.
- Hash functions are often used as a layer of security when sensitive information is stored, & to verify data integrity.