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.
Intro In starting this series, I was confronted with the dilemma of which area of programming should I start with? Testing? Data Modeling? Language Types? All of which are very important topics and areas that any good developer should know. However, I felt strongly that the best area to start was not with code at all but writing.
As a developer we tend to write our code for one person, ourselves.
This is a response to the following article Programming as craft
Programming is a craft. I will never claim to be a master of the craft but to say that programming cannot be considered a craft overlooks many elements of the profession. Sure, groups of developers aren’t building artisan furniture or designing magnificent cathedrals but none of these crafts were perfected overnight and relatively speaking programming is in its infancy.
I am one of the few people who’ve probably traded in their smart phone for a dumb phone. By dumb phone I mean a phone that pretty much just makes calls and texts. For over eight years now I’ve scorned the smart phone market because of the increasing negative effects I feel it has on people. The concept of being constantly connected always presents itself as a great thing but often leads to isolated interactions with people because they are busy checking their Facebook or Twitter feeds or playing some new game.
My last couple posts have been about developing and designing cloud based applications. In the What Are Microservices blog post I wrote about the importance of having small shippable applications that can easily scale depending on demand and are decoupled from other services to allow for faster development and independent deployments. In A Tangled Mess we explored how to decouple the systems even more by publishing events as they occur and having other systems react in appropriate ways.