These days we all are told to build stateless applications. Stateless apps are those that don’t store any state in the application process and fetch any state from a centralised datastore (it could be a global cache or a database). The sixth factor in 12 factor app also talk about the same principle.
Execute the app as one or more stateless processes
Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.
There are advantages in building stateless applications primary being ability to scale horizontally with ease. When we build stateless applications we push the scalability problem to the database. We expect our database to scale horizontally. This usually is solved by sticking a global cache (Redis or Memcached) in between. Scaling cache is relatively easy and solved problem. Keeping cache updated with updates is a hard problem. We will discuss it some other time.
Continue reading “4 Reasons You Might Want To Build Stateful Apps”
I have worked with multiple software development teams that because of feature delivery pressure does not apply best practices. This later leads to tech debt and cost more time. In the last project team that I helped they made two small mistakes:
- They didn’t use pagination in the collection resources. They were fetching the list of data from the database and returning back to the user as JSON. During development when data was small they didn’t face any issues. But, later when customer started doing testing it became a monumental task to add pagination in all the collection resources.
- They were returning domain entities in the response. This meant they were transferring more data over the wire than it was necessary.
So, they were breaking two best practices:
- Using pagination for collection resources
- Keep your domain object different from representation object
Continue reading “Using ArchUnit To Enforce Architecture Best Practices”
Welcome to the 41st edition of my newsletter. I will be publishing this newsletter monthly now instead of weekly.
The three most harmful addictions are heroin, carbohydrates, and a monthly salary – Nassim Nicholas Taleb
Continue reading “Issue #41: A Handcrafted Monthly Newsletter For Software Developers”
Recently I had a to help a team add pagination in their application. The application was built using:
- Spring Boot 2.x
- Angular 7
- Spring Data JPA
In this blog I will quickly show how to add pagination to a Spring Boot 2.2.6 and Angular 9.1.1 application.
To quickly build the application we will use the spring-boot-maven-angular-starter project I wrote a couple of years. It is updated to the latest version of Spring Boot and Angular.
Continue reading “Spring Boot Angular 7/8/9 Server Side Pagination Tutorial”
I love the idea of everything as code. It enables use of version control for all aspects of software development. These days we use everything as code approach for documentation, infrastructure provisioning, deployment automation, continuous integration build jobs, pull request and issue templates, and many other things. The beauty of this approach is that it enables us to use the same tools as we use use for software development.
One aspect of the software development where we are lacking the as code approach is in creating architecture diagrams.
Continue reading “Software Architecture Diagrams as Code”
All software has software architecture. This is true even when a team has not spent time coming up with it. This architecture is often called Big ball of Mud. A big ball of mud architecture is a software system that lacks a perceivable architecture.
Every software system has a software architecture is similar to saying not taking a decision is also a decision.
Continue reading “Architecture Hoisting”
In the last few years I was involved in multiple consulting assignments. In this short post I have shared key lessons that I have learnt on how to better handle and manage consulting assignments.
Don’t give feedback early. Your job for most of the time is to listen.
Start documenting from the first day. Collect artifacts, screenshots, code snippet whatever that might help
Invest time in creating standard templates that you can use for documenting discussions
Ask questions that are open-ended. Don’t let people get away with a simple yes or no.
Make sure you get access to the code base and other software development tools on the first day.
Do the simple possible things. Can I build this application on my machine?
Keep asking why. Ask the same questions multiple times to different people over time. You will get complete picture over time.
Spend a day with the people on the ground. Don’t just hear from the client architect.
Keep consulting assignment duration to max 3 weeks.
Keep SoW in mind. Keep deliverables at max to 5
Don’t put anything in the SoW that you don’t understand or client wants you to add
Ideal team size for a 3 week consulting assignment is 3. Two technical architects and one functional
Learn the basics of customer product domain. Do research on similar products. See if you can find videos or articles on technical details
Spend the first day setting clear expectation. By the end of day 1 you should know the success criteria for the assignment.
Make sure you consider time spent to create report is part of the assignment
Keep 30 mins to an hour every day to clear doubts of the previous day
Keep half day in a week to document any missing piece or clear any doubts
Understand your limitations as a consultant. Don’t get into slippery territories
Know you are valuable. Have self belief. This comes from knowledge and experience.
Dress well. I hate to say it matters.
Don’t get uneasy early because of unreasonable client or difficult conversations. Give time to yourself. After first few days things start becoming relatively easy.
Don’t assume client does not know what’s wrong. People working in the organization know what’s wrong. You have to find what’s wrong quickly and then start moving in the direction of finding solution.
One of the consultant task is to make things visible.
Quickly figure out company politics. Don’t take any sides. Be neutral.
There will be people much smarter than you. Respect them.
Over the last couple of years I have done architecture review of multiple product teams that are on their digital transformation journey. Most of the teams were building products following Microservices architecture. They had all the right intentions to use Microservices based architecture — faster development, better scalability, smaller independent teams, independent deployment, using the right technology for the job, etc. But, most often I found teams struggling with Microservices. They failed to leverage the benefits of Microservices to their advantage. In this post, I will share reasons why I think teams were struggling with Microservices.
For people new to Microservices I recommend reading Martin Fowler’s article on Microservices. I like the Microservices architecture definition mentioned in the article.
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
The list of reasons is below:
- Management underestimate complexity of developing Microservices
- No process to update libraries and tools to the latest versions
- Use of shared services for local development
- Lack of visibility in their version control hosting platform
- No clear definition of a service
- No clear strategy on code reuse
- Polyglot programming
- People dependency
- Lack of documentation
- Feature over platform maturity
- Lack of automated testing
You can read the complete post on Medium.
The time to read this newsletter is 145 minutes.
There is only one way to happiness and that is to cease worrying about things which are beyond the power of our will – Epictetus
- Goodbye, Clean Code. 10 mins read. We sometimes get carried away with clean code.
- Clean code does not always produce simple code.
- As mentioned in the post, clean code is also a trade off. You really should weigh if clean code adds real value or satisfy your inner clean code ninja.
- Another important point mentioned in the post is that you should always take the person whose code you are refactoring in favour before refactoring their code. Explain your rationale and then work with them to improve it.
- A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together
- The No Code Delusion. 15 mins read. I agree with the author that we are still far away from pure no code systems. Most of the no code solutions fail when you want to do things slightly differently. They become limiting and you struggle to keep productivity. They are good for proof of concepts where you want to showcase value faster.
- Why we’re writing machine learning infrastructure in Go, not Python: 10 mins read.
- How To Optimize AWS Lambda Performance. 20 mins read.
6 Lessons learned from optimizing the performance of a Node.js service. 10 mins read
To Serverless or Not To Serverless. 10 mins read. There is nothing new in this blog if you already know about pros and cons on Serverless. But, it is a good written article that you can keep handy in case you need to make decision on Serverless.
A Scientific Approach to Capacity Planning: 20 mins read. This blogs talks about Universal Scalability Law (USL). The USL law takes into account the fact that computer systems don’t scale linearly due to queueing effects.
The Curious Case of the Table-Locking UPDATE Query: 10 mins read. This post by a Heroku engineer talks about how he debugged an issue related to Postgres locks. Good read.
Radical Candor: Software Edition: 30 mins read. This is a long read. It offers a lot of good advice on how to apply Radical Candor in software development. Radical candor is showing care and giving straight feedback. You have to build a relationship with people so that you can be true to them.
The Myth of Architect as Chess Master: 10 mins read. I could relate to the author as I often find myself in such situations. Software development is a cognitive activity and most systems are built over years. So, it is difficult to parachute yourself into a system and provide meaningful advice without spending a lot of time understanding the context and business drivers driving the project.
##Video of the week