People enter into technology thinking they can pursue an idea that will make them a lot of money. If you read startup stories you will find that most start with an idea, evolve into a business, become broke, rebound and make millions…. or end up being broke and learning a lot.
I’ve read these stories but I am not a risk taker. Maybe I just don’t believe in my ideas as much as others or lack the confidence to pursue them.
You should always write tests. To fully understand how to write production level applications in any language you should be able to write unit tests. Some people go to the extreme of doing Test Driven Development (TDD). TDD advocates that you should write tests before you write the code. This can be a good approach when trying to write code that can be easily tested. Yet I find that TDD is a lot like agile; a lot of people say they do it but in reality they do some sort of hybrid version.
In an earlier post I wrote about how to structure Go programs to be leveraged by both a FaaS and a standalone application. This simple application showed the power of what a Hex architecture can do by limiting the need to rewrite logic when an external resource has changed. In that example we looked at changing communication between an HTTP call from an AWS Lambda to a direct application call.
I have a terrible memory. It’s not because I don’t pay attention; there is just too much on my mind. The barrage of incoming texts, work emails, news alerts, and ideas creates chaos. Disconnecting is not an option all of the time, especially for those in the technology field, so what can you do?
It used to be when a computer was running slow or crashing the best solution was to add more RAM, expand its memory.
Functions as a service (FaaS) have really become a staple in most development circles. They provide little infrastructure overhead in the development of microservices and are often very lightweight. Yet FaaS face their own sets of challenges when it comes to costs, response times, and observability.
I believe that architectures will evolve over time. In some cases you may never want to change your FaaS but there may be cases that you’ll want to move it to it’s own application.
I felt that I had a pretty good grasp of what the technology world was like when I graduated from college. After all I just built a series of programs for my classes (of varying quality), none of which had real world applications. I had built systems using live APIs like Twitter and used cool frameworks like Google Web Toolkit. So in the end I felt pretty confident in my abilities even though I had no exposure to the industry.
To be honest, I’ve had a rough time understanding how FaaS fit into my vision of a microservice architecture. It made sense that they were microservices themselves, especially when they are event driven: put something in a bucket, then do something, maybe do something else and so on. But what I didn’t understand was why build a serverless function if you could build an API.
In the end I realize that it was how I had learned to develop microservices that was the crux of my issue.
The main goal of every startup is to make money. Every part of the organization should be driven to create money for the company. This means creating products that users want to buy while decreasing the cost to produce the product all in a timely manner.
In a technology startup the product to deliver in many cases is code. The beginning phases of this process involve a lot of late nights, rapid development, and manual processes.
In the past I have written about what a microservice architecture looks like and some of the tradeoffs that come with it. One of the biggest gains this architecture brings you is the ability for many people to be working on different projects at the same time. Inevitably the services you are writing will be used or you may need to consume someone else’s API to get your work done.
When reading Clean Architecture by Robert Martin, I came across a chapter of the same name. In it the author describes this “idealized” architecture structure where business and application logic are at the center of the diagram with outward rings surrounding it describing interactions with various frameworks and IO devices.
This architecture can also be known as Hex Architecture or Ports and Adapters Architecture, all having a similar design where core business logic is independent of the IO interfaces surrounding it allowing for architectures that are independent of frameworks, ui, and databases.