guest lecture Flashcards

Question

Finnacci : difference between monolithic and microservices architecture

Answer 1

A monolithic application is built as a single unified unit while a microservices architecture is a collection of smaller, independently deployable services.

Answer 2

Start off with a diagram of service components (walk through example on next slide) Outline what your system hopes to achieve at a high level walking through each component on your diagram NB Define your database table(s) structure : Shown in pic to the right Same is applicable for other data storage (s3 buckets) Do this in an entity relationship diagram Define out each column in your database: General description Data type Default/Forign Key/Primary Key? Note any changes to be made to existing DB structure Good DB design saves a lot of pain later After data comes your service : components Do you need an API to handle I/O with other services? Do we need to change existing services? How is input to our service structured? What does output from our service look like? What other services are going to depend on this new service? How does our service account for scalability? Security : How is our data secured? (Encryption) What protocols protect our data in transit? (HTTPS/SSL) Do we use standard protocols for authentication? (OAuth) Do we restrict what machines or networks our service may talk to? (Network Rules) NB Wireframes of your UI i.e. UI diagram (workflow diagrams also good) As you can see this is long and tedious but good work on your plan prevents worse pain later!

Answer 3

It’s great if you design a service that takes the inputs you expect and outputs what you expect! But will it work for 10k users, 250k users, 1M users? Do some of your operations require more time? Could this be assisted by running processes in parallel? Finnaci Example: Problem: Extracting accounts from online accounting system APIs, one transaction at a time is super slow to the point of being unusable at a modest size of data Solution: Make a number of requests in parallel across a number of threads and bulk requests as many records as we can at at a time So how do you design for scalability? Ascertain expected number of users Design for handling between double to triple that amount Determine which processes a user would be fine waiting for and which need to be fast Take advantage of concepts such as : Job queuing Batch processing Parallelization

Answer 4

how do we implement? : A microservice is : Small independent service Component of your overall system Does one small job really well Typically encapsulated in a Docker container : A container is the environment your code is run in Eliminates a lot of issues cause by servers not being setup in the same manner Standard Dockerfile is the setup instructions Easy to deploy Take container and run it on your server So how do I know when to make a part of my project a microservice? : It’s an art not a science Look for natural divisions of work e.g. Logging in and out is distinct from placing an order on a website Look at where you have complex work occurring and try break it down into simple parts Jobs that will take a long time and can be potentially run in the background Use your instincts You’ll improve at this over time

Answer 5

how do we implement? : A microservice is : Small independent service Component of your overall system Does one small job really well Typically encapsulated in a Docker container : A container is the environment your code is run in Eliminates a lot of issues cause by servers not being setup in the same manner Standard Dockerfile is the setup instructions Easy to deploy Take container and run it on your server So how do I know when to make a part of my project a microservice? : It’s an art not a science Look for natural divisions of work e.g. Logging in and out is distinct from placing an order on a website Look at where you have complex work occurring and try break it down into simple parts Jobs that will take a long time and can be potentially run in the background Use your instincts You’ll improve at this over time

Answer 6

After all your hard work how do we ensure we don’t stray from the design? : Acceptance tests Written before coding the service to ensure when we write the service it does what we want Unit tests Tests how small parts of the system work e.g. Test if function X returns an int Integration tests : Ensure the full workflow of the system operates as expected Test integration with other service e.g. Can we send a request to service X and get response

Answer 7

What is infrastructure? : Servers Network switches Cloud resources (can incorporate the previous points) Power infrastructure (at the scale of Google) All the components required to run your application Typically managed by DevOps : Smaller companies and startups would incorporate this into regular dev duties

Answer 8

What is infrastructure? : Servers Network switches Cloud resources (can incorporate the previous points) Power infrastructure (at the scale of Google) All the components required to run your application Typically managed by DevOps : Smaller companies and startups would incorporate this into regular dev duties

Answer 9

Your infrastructure plan is critical for knowing where your system will operate It will be the main determining factor for costs It is critical for the security of your application It is covered in your system architecture document which should consist of Your infrastructure plan

Answer 10

Your infrastructure plan is critical for knowing where your system will operate It will be the main determining factor for costs It is critical for the security of your application It is covered in your system architecture document which should consist of Your infrastructure plan

Answer 11

you should (if applicable) detail : The various parts of your system (i.e. each service and how it communicates with the others) IP Address Ports Whitelisting rules 3rd party services you need to communicate with Databases (include what type e.g. PostgreSQL, MySQL etc.) Networks (AWS VPCs) Firewall DDOS Protection (Cloudflare) Desktop services There is a lot to cover but some items require more information than others

Answer 12

It is important for internal reference and to reassure investors & users Start off with Whitelisting rules : Users from the DCU IP range (136.206.0.0/16) can connect to server with IP address (192.168.0.1) on port 22 with the SSH protocol Do this for all servers and for all requires open ports Group your system into isolated networks: Some services will never have any need to talk to one another They can therefore be isolated from each other on different networks Tell us what protocols will be used for communication : Are external communications secure over HTTPs? Are internal communications in plain text? What parts of your system sit outside your firewall? (i.e. could be user accessible) Tell us how data is securely stored (i.e. do we encrypt data?) GDPR puts imposition on business to design with security in mind Design to ingest the minimum amount of data required : Mo’ data Mo’ problems (to paraphrase Biggie) Data now has an element of liability to it Be mindful and write a policy document later about how you’d handle a data breach Store data in an anonymised fashion to reduce liability Never store passwords in plain texts (hash & salt) Be aware of a user’s fundamental data rights while designing

Answer 13

Budget for x2, x3 of what you need (scalability factor) How does your system handle resources falling over? Do you run backup servers or not? If you have many servers you’ll need to consider load balancing Use your providers budgeting tools to plan Use your providers cost monitoring to keep an eye on things Check regularly as you may set and forget a resource you don’t use If you are using a high amount of resources reconsider your systems design Try keep resource usage to a minimum

Answer 14

Budget for x2, x3 of what you need (scalability factor) How does your system handle resources falling over? Do you run backup servers or not? If you have many servers you’ll need to consider load balancing Use your providers budgeting tools to plan Use your providers cost monitoring to keep an eye on things Check regularly as you may set and forget a resource you don’t use If you are using a high amount of resources reconsider your systems design Try keep resource usage to a minimum

Answer 15

When using cloud resources avoid vendor lock in! When you use resources that are hard to migrate away from later These resources are typically : Very easy to use Cheap to begin with Pushed hard by the cloud providers These resources will be : A nightmare to debug issues with Expensive in the long run An absolute PAIN to migrate away from Long and short of it don’t use preconfigured solutions from cloud providers Exception, you may use managed services that just takes a container and runs it or takes some code and runs it (i.e. serverless/cloud functions)

Answer 16

Touched on this a moment ago regards allocation Think about how this is achieved! Do we scale vertically or horizontally? : Vertical Scaling = Make current server(s) better, faster stronger (yes I love dated references) Horizontal Scaling = Add more servers and split the traffic What is the process for scaling up resources? : Are we using a system to manage our infrastructure like Terraform? Change the configuration for our infrastructure Do we manually provision resources? Get the DevOps lead to rejig things in the cloud providers What’s the impact on budget from scaling? Does the scaling of infrastructure meet business requirements and user needs?

Answer 17

Assign ownership of this job specifically : If who is responsible for infrastructure is vague, it will be managed badly! Try automate as much as possible : Deployments and infrastructure management are boring tedious tasks It’s therefore easy to do wrong Set and forget with automating (CI/CD/Terraform/Ansible etc.) Choice of cloud provider should really just be done on basis of cost and ease of use If you have the budget, get your people responsible for infrastructure management certified in the chosen cloud providers stack Alway monitor resource usage over time

Answer 18

Assign ownership of this job specifically : If who is responsible for infrastructure is vague, it will be managed badly! Try automate as much as possible : Deployments and infrastructure management are boring tedious tasks It’s therefore easy to do wrong Set and forget with automating (CI/CD/Terraform/Ansible etc.) Choice of cloud provider should really just be done on basis of cost and ease of use If you have the budget, get your people responsible for infrastructure management certified in the chosen cloud providers stack Alway monitor resource usage over time

Answer 19

Your plans will be out of date the moment you start implementing This is due to changing business requirements and user needs Always get feedback on your implementation and be willing to change If you deviate from the plan UPDATE THE PLAN DOCUMENT! The goal is to be well prepared Things will still go wrong This minimises problems Provides accountability Helps make you and your product look better than the rest!

Answer 20

Designing out your system prior to implementation is very important You are saving a lot of future pain! Security should be discussed in both contexts but especially in Infrastructure Diagrams are your friend Avoid vendor lock in

Answer 21

Designing out your system prior to implementation is very important You are saving a lot of future pain! Security should be discussed in both contexts but especially in Infrastructure Diagrams are your friend Avoid vendor lock in