What is a microservice architecture? Why should I use it instead of a monolithic architecture? The microservice architecture has actually been used for a long time, it’s only in the past few years that it’s been caught on to as a buzzword. The gist of this article is that monolithic architectures were great until we started adding more teams to the mix. An application became harder to manage, development slowed down and releases took longer to ship. Microservices solved a lot of these issues
Monolithic Architecture – Where it all began
The most common type of architecture that applications use is known as a monolithic architecture. This simply means that the whole application is held together in a single application. This one large application would contain all the business logic for every user story that’s implemented.
The problems with a monolithic architecture
Monolithic architectures worked pretty well due to their simplicity. New features and updates to an application were pretty easy to implement for a single team. Until we added more developers and more teams. Now we’ve got this huge application that multiple teams are adding and updating code for. This resulted in a bunch of other issues.
Due to the high amount of coupling the number of conflicts when committing code increased
This also reduced the interval between deployments because multiple teams had to co-ordinate with each other in order to release their application. Every change required some sort of impact analysis
Code quality was also a problem due to high coupling
Crashes in one part of the application would affect the entire application
You can’t scale parts of the application that are used more without scaling the entire application
Microservice Architecture – Where we are now
Microservice architecture is different from a traditional monolithic one because it focuses on splitting out a large application into independently deployable services. Having an architecture solves many of the issues above with the addition if each service being simpler and easier to develop and deploy. Changes to one service no longer require the entire application to go down, only that small isolated service. Performance bottlenecks can be identified and scaled individually. Individual services can also be managed by different teams. Microservices also map better to the real world by organizing them by business processes.
However, microservice architectures also come with their own challenges such as logging, service discovery. When a microservice architecture is poorly planned, you can end up with many more problems than you started with. It also introduces much more advanced topics such as event sourcing and understanding the proper size of your microservices. It’s difficult to know the exact size a microservice should be and it’s also difficult to know what would be dependent on one in the future.
The bottom line
Microservice architecture is an effective method of tackling a specific set of problems for large enterprises and teams. When implemented correctly and for the right reasons, a microservice architecture can provide a huge amount of benefits and can improve development speed significantly. However, taking the leap should be evaluated carefully since it’s definitely not for the faint of heart. Monolithic architectures are also a great option for small to medium-sized enterprises. Sometimes implementing a proper deployment pipeline, automating tests, good software architecture and applying good coding standards is all you need.
If you’re a solo developer and looking to implement the next shiny thing, then microservices is probably something you want to skip. The added complexity can actually reduce development time and increase complexity. If I was building a small application for myself as an MVP (minimum viable product), then I’d definitely go with a monolithic architecture due to the sheer simplicity. Using a good architecture is more than enough in this scenario. The main thing you want to focus on is building and shipping your product as fast as possible. Hey, if it ends up being a success, then pay someone else to implement a microservice architecture for you!
I currently work as a Software Engineer and I also have a degree in Computer Science. The purpose of this post isn’t to turn anyone away from education. This is just my honest opinion on why I think a degree can’t teach you how to be a better programmer.
Software Engineering is a practical skill
Although there’s a lot of theory behind programming and software engineering, programming is a practical craft that requires loads of practice. It’s easy to think that a book will teach you how to be a better programmer but the truth is, practice is key. Courses, books, and degrees can only provide a guide on how to be a better programmer.
So why study a computer science degree at all?
It really depends on what goal you’re trying to achieve by getting a degree in computer science. If you’re looking to further your academic knowledge then sure, go for it. Computer science is a vast topic and there are loads of areas to explore.
However, if you plan on becoming a better programmer then it’s most likely not a great use of your time or money. It also largely depends on how your course is taught. Most university courses don’t simulate real-life programming. Computer Science is a really broad topic and your course will most likely give you a taster of the various different fields within what’s considered Computer Science. Most of what you learn will be based on theory rather than how something is applied in real life. You can think of a university degree as an introduction to the computer science field as a whole.
A computer science degree can give you a good foundation
Sure, my degree introduced me to a variety of useful topics but it’s highly likely that I would have encountered them at some point during most projects I worked on. Most of what I’ve learned is due to my experience developing real applications. Keep in mind, when you work in the real world, you’ll be working with developers who are far more experienced than yourself. There’s a huge amount of knowledge sharing that takes place on the job.
But can I get a software engineering job without a degree?
One other reason why you might want to get a degree is to get a job. The job market is getting more and more competitive. Simply mentioning that you have a degree automatically ahead of those who don’t. Maybe that sounds harsh, but the reality is that most of the time before a human even reads your CV, it’s filtered by an ATS (Application Tracking System). There’s a lot of companies that require you to have a Computer Science degree but at the same time, there are companies that don’t. These days many companies look at projects you’ve been working on in your own time. There’s already plenty of developers who already have a job without needing a computer science degree.
How to be a better programmer?
Practice, practice, practice. Work on your own projects. Software Engineering is a practical craft that’s honed through practice and experience. A person with hands-on experience and a few projects under their belt would be far better programmers than a degree holder.
The bottom line
Software engineering is a practical craft that should be improved over time. Learning theory is great but applying your knowledge is what’s going to allow you to become a better programmer. Learning to apply what you’ve learned is even more important. In the UK a university course costs £27,000 and a minimum of three years of your time. Most university courses focus much more on theory than they do on real-life applications. So that’s my take on why I think a degree can’t teach you how to be a better programmer.
Is it really possible to learn to code 100% online? Well, maybe. It definitely sounds appealing, especially since University degrees could burn a hole in your pocket. Of course, there’s a difference between knowing how to code and being a developer. But we’ll get to that later.
The truth is, it definitely is possible to learn to code 100% online. It might not be easy, but it sure is possible. Also, online doesn’t necessarily mean free. There are loads of online courses available these days that help you to learn to code. There’s plenty of courses available. Some offer income share schemes like Lambda school. Other course providers ask for a straight-up fee with loan options.
But is it possible to learn to code 100% online for FREE? Damn right it’s possible. It’s also possible to build your own car. But does anyone have the time? I’m not saying that to turn you off, but if you plan on diving into a whole new world without a plan then you’re bound to run into trouble. So what do we need? A plan of course!
How to learn to code online for FREE?
No, I’m not trying to sell you anything and this isn’t some clickbait. Learning to code 100% online is definitely possible, and you can do it for FREE. The first step is to gain a solid foundation. Programming is a huge topic in itself, so we’ll just start with web development. Once you gain enough experience you might want to venture into other types of programming and development. There are a few topics that are essential for every programmer to understand. I’ve listed them below with some resources for you to get started.
Client-server relationship. Understanding the process that takes place when you visit a website, click a button and what actually happens behind the scenes.
Documentation. This is probably one of the most important topics. Documentation is basically just instructions, and definitions for programming languages, frameworks or libraries. Kind of like a reference or instruction manual. Learning how to read documentation is a skill you’ll use even when you’re an advanced developer. This skill will give you loads of confidence in working on your own projects. Some examples of
What are frameworks and libraries? Just getting to grips between the difference between frameworks, libraries and programming languages.
One really great course that can help you along your way can is the free course by freeCodeCamp. They have a great set of projects to work on too.
The bottom line
In the near future, I’ll be creating some more articles diving deeper into some of these topics. Hopefully, this will give you a good start though. Of course, the more you practice the more you’ll learn. These are pretty much the core set of tools. You might want to carry on and explore on your own from here. Or stay tuned for more advanced topics in the future.
As solo developers, we’re always trying to find the best services for the job without emptying our pockets. I thought I’d write a short article about what I think are the best services for solo developers. These help me minimize costs while also giving me loads of functionality. Hopefully, this will reduce the amount of time you spend deciding which services to use.
When working on a new project two of the most important things to me are cost efficiency as well as ease of use. I like to focus purely on development with as little infrastructure management as possible while always minimizing cost. Although cost seems to be a trade-off for low infrastructure management and ease of use, it doesn’t always need to be. I think I’ve found the best services for solo developers. They work perfectly fine for me anyway.
Version Control is a part of every developer’s toolset. For me, Gitlab is a winner. Not only because it provides version control but also because it has a whole suite of tools for creating and managing DevOps pipelines. It’s super easy to use and guess what? It has a generous free tier with unlimited private repositories as well as free build minutes per month. If you’re a solo developer then the free tier should be perfectly fine.
Project management for solo developers
Trello is my tool of choice for project management. It’s easy to use and good for quick task management.
Depending on your use case and latency needs you’ll either be able to go for a serverless option or have an actual VM on AWS Lightsail. For solo developers, the fully managed, auto-scaling services out there are too expensive for the size of the instance you’re going to get. At this stage in your project, it’s most likely not so important to worry about how your application is going to scale to multiple instances. This is one of the cases where I would sacrifice infrastructure management for cost.
If you go down the serverless route, you’re definitely going to need to take a look at the Serverless Framework. This works perfectly on AWS. One of the key benefits of going serverless is that you’ll have virtually no startup cost since you’ll be paying per execution. This means if a project isn’t as successful as you thought it would be, at least you never lost any money maintaining it.
An excellent CDN that I use is Netlify. It integrates well with any deployment pipeline with its CLI tool. You can connect it up to a git repository too.
I personally like to use CloudWatch since it integrates well with Lightsail. It’s pretty easy to add it to a docker-compose file too. I’m sure there’s plenty of other tools available but this is really all I use. CloudWatch has a generous free tier too.
If you’re building a project that relies heavily on file storage I would use AWS S3. This is one option that also offers a free option. However, There’s also another great service that I’ve recently been exploring which is Wasabi. Wasabi doesn’t offer a free tier though and requires a monthly fee. For large amounts of files, it can end up being 80% cheaper than S3. At this stage, it’s probably not super important though. As solo developers building small applications, if we’re storing 5GB of data (S3 free tier) then we’re likely making enough to make that investment.
For authentication, I generally use AWS Cognito but there are also other providers like Firebase. Both of which provide a generous free tier.
There are two main types of database technologies that you’ll choose from. SQL and NoSQL. In terms of the technology itself, I prefer to use SQL databases. The main reason is that when I work on a project, I don’t know all my data access patterns from the start of the project. That’s an important point to keep in mind if you decide to use NoSQL. There’s a lot of companies that have used serverless NoSQL services and ended up with a huge bill because they never designed their data correctly.
If you do go down the NoSQL route then there’s a number of options that provide fully managed services with free tiers available. The most famous ones being AWS DynamoDB, MongoDB Atlas as well as Google’s Firebase. All of which are pretty solid options. If you’re a solo developer and worry about cost, then it’s unlikely that you’re dealing with huge amounts of data. In this case, you should probably go with something like MongoDB Atlas. Of course, as with all NoSQL database, it requires a lot of upfront design when modeling your data.
If you go down the SQL route then, unfortunately, there’s not a lot of managed database services for solo developers. You’ll need to fork out a bit of cash for a managed database service. Managed database instances on AWS Lightsail start at $15. Otherwise, if you want to trade off database management for cost then you could just as easily use AWS Lightsail for a tiny instance to host your own database for as little as $3.50. You’ll also need to install the database yourself too.
The cheapest option, of course, is to host your database in the same instance as your application. For development environments or applications that don’t have a lot of users, this is completely fine. As for the database itself, I prefer to use PostgreSQL.
Email services for solo developers
Most applications also need an email provider for both transactional and marketing emails. There’s a huge amount of these providers, but not a lot of them are great services for solo developers. My go-to option is SendGridsince they offer a decent free-forever option which includes 100 emails per day. If you’re sending 100 emails a day then you’re likely making enough to pay the cost for one of their plans. Yes, there is AWS’s Simple Email Service, which is super cheap, but it lacks a lot of features that a service like SendGrid gives out of the box.
The bottom line
Taking everything into consideration, if you go down the serverless route then you’re likely only going to need an instance for your database which is either a monthly cost of $3.50 unmanaged or $15 for a managed database. Picking services for solo developers can be a long process and can hinder development progress. I hope these notes helped you out. Sometimes it’s a good idea, not to over-optimize your application and just choose the options that will allow you to get things done as fast as possible and optimize later. The most important thing is to get a project finished and shipped as quickly as possible so that you can get feedback and iterate on your product. If that project ends up being a success, then pay someone else to worry about it for you!
There isn’t really a proper definition for unit testing other than unit tests test small units of code. How small is small? Generally speaking, it’s a class. When we write a unit test for a unit, we’re basically asking if this unit is fulfilling its responsibility and working the way it was designed. These are different from integration tests, which test how multiple units function together.
Focus on test quality over test count
There’s no magic number of tests you need to write for a project.
Focus on good quality tests that will add business value rather than aiming for 100% code coverage
Write unit tests for core business logic
Don’t test libraries
They provide huge benefits in terms of maintainability and longevity
Why I need unit tests?
When written properly, unit tests can improve software quality.
They make it easier to refactor code without breaking other pieces of functionality.
They make code more maintainable.
Since unit tests deal with small units of code, it makes it easier to pinpoint broken code after a build.
They make it easier to identify bugs earlier on in development
They can improve your overall code quality. The main reason being that unit tests force you to write clean code so it’s easy to test. Poorly written code can be harder to test
When implemented correctly, they can reduce costs since bugs are found earlier on, reducing maintenance costs
How many unit tests?
This is quite a debatable issue. Some developers swear by unit tests and are determined to get 100% code coverage, while others hate the sound of the words. The key is to strike a balance. There’s definitely such a thing as too many or too few unit tests. But the answer isn’t so straight forward since it depends. I think a better question is…
When to write unit tests?
One rule that I apply when deciding when to write any test (not only unit tests) is to ask myself how much business value will this unit test produce?
The best unit tests you can write are the ones that test actual business logic or complex algorithms. Focus on writing high-quality tests rather than aiming for 100% code coverage and testing for that goal only. Poorly written tests will result in higher maintenance costs since you’ll spend loads of time fixing or rewriting broken tests. Remember, it’s better to have a few high-quality tests than having many poorly written ones. CBC
It’s easy to go overboard and write unit tests that are not very useful and don’t really add any business value. For example, if you have a method that performs one simple action like calling a library and returning the result.
// Example pseudo code that shouldn't be tested
var client = new Client();
var result = client.getData();
Then it’s not really beneficial to test that method at all. A method like this wouldn’t be considered business logic. However, a method that contains core business logic should definitely be tested.
// Example pseudo code that should be tested
if name field is empty or length is more than 250 characters
if description is empty or length is more than 3000 characters
var client = new Client();
var result = client.save(name, description);
So, the more business logic you have, the more unit tests you should have.
I’ve seen tests that have been written to check that a library works the way the documentation says it should work 😬 The internals of a library should be tested by the author. As developers, we should consume a library and assume it’s working as expected. If you think that you need to test a library because it doesn’t seem reliable, then maybe you should be asking yourself if you should be using that library in the first place 🤨 The same applies to calls to your repository layer. There’s often not any actual logic in your repository layer, so it rarely needs testing. The ORM or tool you’re using in that layer should already be tested by the author.
But we’ve got legacy systems without unit tests and they work fine
This is often an argument brought forward in order to not write any unit tests. Although it’s great that an application is working fine as it is. An application without unit tests is difficult to refactor or extend without knowing if you’ve broken anything.
But it’s like writing double the amount of code
It’s not uncommon to work at a place that doesn’t understand the need for any type of testing. Of course, you should focus on convincing the higher-ups of the need, but to start out, it’s difficult to budget any time for tests. If you’re in this situation, leave…
If you have a good architecture in place and you’ve implemented good practices when writing code then tests shouldn’t take too much work to add. Implementing functional principles, and having a layer in your project that contains business logic will also help too.
The bottom line
These are just my opinions. Testing for developers is one of those topics that everyone has an opinion about. Some love them and some hate them. When code is written cleanly and is well structured, unit tests require little effort to write but provide huge benefits in terms of code maintainability and longevity.