First Post - Overview of blog

 


About Me

Ive been a programmer/analyst/engineer/consultant/company owner/tech lead/team lead/architect for the last 30 years since 1987. Ive worked on many systems, in many languages, with many different stacks and different teams. Ive worked on small systems and very large complex systems. 


The Question

What does it take to put together a system in 2023. What architecture to use? What tools does a programmer need to know? How does one even start on the design? 


The System

Lets do a banking system. Lets make it production ready. 


The Architecture

We want this to be as realistic as possible to show all the components that make up a modern production system and we want to take as modern an approach as possible, so here is our basic architecture

  • Data storage - a combination of RDBMS and NoSql tools
  • Application - web front end, micro-service back-end 
  • Micro-service - each service is a stand alone API driven application
  • Core Library - a library as small  possible used in each service for standardized communication
  • Communications - REST calls and Message Queues 
  • Orchestration - using Kubernetes to manage services
  • Logging - using a log aggregator to archive logs
  • Source control - using GIT for source repositories
  • Build system - using Jenkins for build pipelines
  • Artifacts - storing artifacts using an artifact management tool 

Keep it simple, Stupid

The KISS principle has largely been lost in modern software development (which is why we have all these multi-million dollar multi-year overages).  We will stick to the KISS principle as much as possible  in this implementation, explaining decisions we make and why we make those decisions.

Overwhelmed yet

There is no doubt modern software applications have complex stacks which are overwhelming, leading many technical leads and engineers at all levels to feel they have the imposter syndrome, because they really dont understand every aspect of the stack. It is not helped by some know-it-alls or self-claimed experts who insist their way is the right way, or someone elses way is outdated or "old way of doing things". We will explore these claims in this implementation but be prepared to be overwhelmed and try not to panic. When broken down to its simplest form, the application is quite simple. 

Lets Go

Hold your horses, we need to do some prep-work. Remember measure twice, cut once. That is very true for software implementations.  Each blog will build on some concepts leading up to the final implementation details.

Comments

Post a Comment

Popular posts from this blog

Implementing a web application over time

 HTML/Javascript First there was HTML where styles were attributes of the HTML tag and we used Javascript to create simple dynamic components such as a timestamp that updated every second. A web client (a browser) would request a HTML page from a web server using HTTP and a URL, the web server (normally running Apache or NGNX or Tomcat or similar server software) would send the HTML and Javascript files back to the web client to be displayed. The contents of those files were interpreted by the web browser software running on the client and displayed to the user.  HTML/CSS/Javascript Next,  we separated the styles into a separate file and referred to the components we wanted to style. This led to very cool sites like CSS Zen Garden where the same HTML could be themed to look much different just by using a different CSS file containing different styles. Server Based Pages A web client (the browser) calls a webserver which sent back HTML, CSS and Javscript files. Using the s...
Read more

Components of the micro service

 Components of a micro service A micro service is no different from a service in a service orientated architecture. It is a standalone application with an API that is defined. Each API call performs functionality such as updating the database, retrieving data from the database, creating files, sending messages etc.  In our application we will be supporting a REST API  and a MessageQ API. The REST API uses the HTTP protocol. This means our application must have a built in web server that can process HTTP messages and output JSON formatted data.  All synchronous requests will be sent using the REST API. Our API must use HTTP status codes correctly, parse the header records correctly, implement security with bearer tokens (explained in a later blog post). Every service that uses our API must be able to process successful and unsuccessful response codes gracefully.  The MessageQ API uses a queue name and a message with an ID and a payload. All messages will be sent ...
Read more