The What
Humility I don’t know is not only an acceptable answer, it is almost always preferred to me over trying to BS a question.
When to ask? When to search? Based on my previous item I want to see that the candidate will in fact know when to Google around, and do some trial and error. As opposed to asking a colleague or boss. Time is valuable. That means spending several hours of their time researching and trying is preferable at times. At other times its a complete waste. Having the sense when to inquire and when not to is extremely important.
Self-Starter I’m a person that never really needed someone to stand over my shoulder. I don’t expect my employees to do the same. I don’t expect to babysit. For more junior employees I expect a manager will be involved ensuring they are where they need to be.
Skills The last thing I look for is the actual skills. Depending on the timeline I would often prefer the better overall candidate who may have similar but not the exact skills. Learning new skills takes time, but intelligence, knowledge, and experience are more valuable.
The How There are some specific questions I ask and subjects I mention to attempt to verify these items. A big thing I will always do is ask questions in a domain or specific discipline that the candidate does not have experience in. I tell them they can ask me questions and I will help them where I can. If they just give up on the spot, next! If they try to BS their way through it, next! I want to see them take their existing experience and try to investigate the problem
]]>Let’s say you had a database of books and their respective contents. Now let’s imagine there is a store/library thing maybe somewhere in between Gartner and Safari Online. You have access to millions of resources but there are different packages what you have access to depending on your plan and what resources you have purchased. To access an individual item is fairly simple, the application layer just needs to ensure that you have access to that single resource. However, if you wanted to perform a fulltext search throughout all of the resources you have access to this can be a very complex process. No matter how you perform it there is waste with pagination and caching or time to reprocess the data-set. Theoretically you could write stored procedures for a SQL database and attempt with a single query to access the exact results for the exact page requested. Suffice to say such a store procedure would be awful to engineer, test, and maintain. It is without question that at times creating stored procedures may be the most efficient way to extract data. Very few companies will do this anymore at all. They will move towards large caches and application layers. With the gradual push to doing more and more computation in a serverless manner the latency and processing time grows exponentially. The pros and cons of serverless architecture are outside of the scope of this article, however it is clear that if the serverless process is connecting directly to a database (something I generally advise against) the overhead involved in openning the sockets and connecting to the database puts additional burdens on the database and the network infrastructure. Let’s instead adjust our approach and use a very unconventional approach to truly blur the lines where application and database exist.
PL/Java is a free open-source extension for PostgreSQL that allows stored procedures, triggers, and functions to be written in the Java language and executed in the backend. I’m not suggesting that this is novel or going to solve big problems. This extension will allow engineers to create code that interacts directly with the database that is a great deal more comprehensive and accessible than what any SQL variant will offer. This may have a tad of a performance gain, but ultimately it would minimize the network traffic.
Without knowing the internals of databases as I have spent a nice amount of time understanding how several of the major databases are written and function end-to-end. The one thing you need to know is that the query inputted at some point in time is parsed and that helps the database determine what data needs to be accessed and ultimately what that query plan is. If you are somewhat familiar with the interpreted languages like Python everytime you run an application written in Python the code is converted into the low-level machine code appropriate for the current system. The runtime environment may be able to cache and optimize this overtime and improve performance. A database is similar in many ways as it is really an application (of course). Now imagine that in addition to understanding the query language, like SQL that the database also understood the actual Python of Java code. I don’t just mean that it executes the Python or Java code like in the PL/Java extension where the database has no idea what the extension is doing. Rather, in this case the database would be able to compile the application code down into something that the database can understand just as much as a query.
Here is a free online archive of the LOTR series text. This is an example database schema for handling our sophisticated library system.
Book
* id: bigint
* author: bigint
* pages: int
Author
* id: bigint
* name: varchar(100)
* locationId: bigint
Page
* id: bigint
* bookId: bigint
* chapterId: bigint
* page: int
Chapter
* id: bigint
* bookId: bigint
* index: int
Word
* id: bigint
* word: varchar
* root: bigint
WordRoot
* id: bigint
* text: varchat
WordPage
* id: bigint
* wordId: bigint
* pageId: bigint
* index: int
WordChapter
* id: bigint
* wordId: bigint // Word's Id
* chapterId: bigint // Chapter's Id
* index: bigint // Word's order from beginning of Chapter as origin
Location
* id: bigint
* name: text
* latitude: double
* longitude: double
With the schema present one could find words or their root within a given proximity to each other. I’m going to use the classical fantasy series The Lord of the Rings by J.R.R. Tolkien. Maybe we want to find a conversation with Saruman and Gandalf. Perhaps we hope to accomplish this by looking for the words “Saruman” and “Gandalf” with a maximum number of words distance. For this first example let’s say that the user may choose purchase each chapter of the book on its own, each book of the series on its own, or the entire series at one time. The task of finding the words within the specified proximity isn’t too complex. Keep in mind that the end of sections like with series of asterisks, or a separate chapter should be disqualified from the distance search. Meaning that if the word “Saruman” is found close to the end of chapter 1, and “Gandalf” is at the beginning of chapter 2, even the distance between the two words may be within the specified threshold the result must be excluded because the chapter break clearly separates the context. Let’s look at the simple steps involved here:
Now to write this as a single query will be incredibly complex and very likely subject to errors. Not to add to the complexity, but very often services like this will still like you to know how many results may have been found from items that you may not yet own. This provides an incentive to sell you those items. The type of queries needed here are complex and demanding.
If this task was limited only to the Lord of the Rings series and was a tool for the incredible geek that wants to search through Middle Earth with great preicision, this is not that bad. Truthfully, if this was limited to a three books you might say drop the database and just store the text in memory. Let’s approach it from that perspective for the moment.
]]>I’ve had a nice amount of exposure to the Golang language when I first started playing around with docker and its environment. At one time I actually had to go through the docker source code and the accompanying kernel source code for namespaces, cgroups and some other stuff. I had done some simple code execution and modifications but not a large scale system design.
I wanted to design a serverless system to emulate the calendaly service functionality. I’m all for paying for services, but not something that I could whip up myself quickly. I am still in the middle of my post how I eliminated Wordpress and managed to avoid paying for siteleaf. I usually use these use cases as oppurtunities to play around with something new and different, as opposed to just using some tool I could pay for…what fun is there in that?
I have a nice amount of meetings with people from consulting to networking and like the idea of having a simple url to easily allow a perspective meeting to be booked without exposing my calendar. Since this was more of an experiment with Golang and to see if I can pull this off as a serverless model with minimal fuss I had a fairly generic set of requirements. My initial requirements were:
I had another challenge for myself and that was to see if I could do this without needing any additional storage mechanisms beyond the Google calendar.
I decided to extend this initial MVP and start with a schedule model first. The idea of this schedule model would be able to define general boundaries that guide your daily and weekly calendar. I came up with this approach:
enabled or disabled. A disabled day is not even taken into consideration for any schedulingbusy.I realized that the state of Availability can be one of three:
Busy - A known eventAvailable- A known free slotUnknown- There is no rule which indicates that the time is busy or freeYou may ask yourself…what’s with the unknown…if you don’t have anything on the calendar don’t you just assume you are free? The answer is that it depends on what type of calendar this is.
]]>This article is not about the actual language you use as much as it is about the architecture you use. This example is in fact a web-based game. Generally JavaScript is the language used for scripting in the browser. I’m not going to deal with that at all right now. In fact I’m going to create a very simple Java version of the same game that has a Java backend. The first version will be ascii based and
I recently read this post and believe that many companies who jumped quickly on the microservices wagon may have many similar challenges.
As always I am going to be very direct and to the point. The businesses I have in mind in this article are growth oriented. If you are a small business unit that only has small goals please recognize that best practices need to be adjusted for each organization.
This is going to center around the general architecture for a complex system for an enterprise organization.
I have recently noticed an increase in clothing labels using the phrase “one size fits most”, I just wonder if someone sued and they stopped saying “all”.
I use this quip regarding #software #architecture.
There is simply no “one size fits all”.
A great deal has been covered on the topic of microservices, containerization, and serverless by many very smart people. I’m hoping to provide some direction and specific techniques.
I’m a big fan of the Spring Framework and their design patterns. Even if I’m not using the Java language I try to best follow many of their approaches. To begin with some very simple items that cannot be overstated Less is more, keeping things simple, isolated, and not repeating yourself are all really one.
Now without talking about SOA…whatever that is. Let’s focus on simply interfaces. If we create our code with strongly typed interfaces anything and everything we talk about after this point should be simple. I’m going to restate that. If we properly design our code with strongly typed interfaces and focus each interface on a very select set of capabilities. You will always be in a pretty good position.
What I’m trying to tell you is that before you even look at the monolithic or microservices discussion, you must be at this point. I haven’t mentioned infrastructure, DevOps, testing, or anything else. Those are important, but ultimately your code having proper modular (keyword) architecture is paramount.
Utilizing modules, packages, or namespaces you can modularize your code. Again, nothing new here at all.
I’m a big fan of object oriented programming, despite its recent bad reputation.
Let’s say I have an enterprise system that connects event-driven applications.
I want to allow the user to be able to upload a new jar file to s3.
From that jar the system may dynamically load and unload modules and subscribe/unsubscribe to specific events.
With java I can dynamically pull the jar object.
Then I would read through the jar and look for any classes the implement the established interfaces.
Let’s say that we have an interface called MessageConsumer:
public interface MessageConsumer<T> extends java.util.function.Consumer<T> {
// Returns an array of strings
// that are used to subscribe this
// consumer to the topic.
String[] getSubscriptionTopics();
}
Let’s say that we have a jar with a few implementations of that interface in it.
The system would automatically load those classes and subscribe them to their respective topics.
Now this jar was added dynamically at runtime by using a ClassLoader.
With the same sort of jar isolation you can simply have various jars loaded like dependency in a maven project.
https://www.martinfowler.com/bliki/MicroservicePremium.html
The need to refactor isn’t a sign of weakness or lack of foresight. However, iderally refactoring should really only be needed when an actual business case changes. Let’s look at the classical board game of chess for a moment. I’m not the best player around but I have a strong appreciation for the game. I have used this as an interviewing technique. I’d ask the candidate to begin to design a chess game. How would they start? What would the general system look like? Now I would never expect the candidate to anticipate what if we want to change the chess board to three dimensions. What if we added additional players? What if we created new pieces? Some of these items may be so intrinsic to chess that the thought of considering one way or another was simply not considered. Functional programming is very populuar now. Much like agile, functional can be a crutch for poor architecture. That should not be the case. Even a functional approach should have strong isolation of concerns. The terminology of your approach is not as important as the approach itself. Whether its a callback, observer, factory, facade, etc.. it’s not the name but what the approach provides you. You don’t need an object oriented language to write good clean code, but it helps. A statically typed language for enterprise application isn’t an option, it isn’t a debate, it is simply the law. Luckily the compilers today have evolved and are quite advanced. They are able to follow inferences and eliminate a great deal of extraneous boilerplate code.
So what is the trick to always start off with the best architecture and limit the number of times you need to refactor? It is quite simple. Design reality.
Let’s start with chess. If you look at some chess boards they have letters and numbers. These are used to accurately depict a position without having to use your fingers to point. In general with computers and engineering if you need to point or make a gesture for a reference, the resolution of detail is lacking. Hopefully you are familiar with the cartesian coordinate system that you learned in grade school. Even if you aren’t familiar with it, even without a formal definition of the system you are most likely acquinted with it already. Simply enough, you have a range of numeric values each associated with a given axis. There is a great deal more to it, and if you take the time you will appreciate a lot of what probably put you to sleep at one time. Sadly, most of the math that I learned in school was memorization and whatever was needed to pass state exams. I’m not really a math guy, so be warned I’m out of my element, and welcome any useful comments.
The standard chess board has axises. Each with eight positions. Totalling sixty-four total positions. A unique position is defined at the intersection of a point within each axis. There are several pieces, each with their own rules. I always start off by trying to establish the objective of the system. Chess is a game, an amusement…but let’s talk about the objective of playing the game and not to have fun. The objective of chess is to prevail either by your opponents resignation or putting them into checkmate. Chess is a turn based game. That means that each player must move a piece each sucessive turn. In some turn-based games a player can “pass”, that is not an option in chess. Without even getting into specifics the important thing to establish is that the game of chess can be represented as a state machine. Chess has absolutely no random component associated with it such as a rolling a dice. Why is a state machine significant? A state machine means that you can represent the exact moment in time of the game in a way such that you can replay the game from its inception and recover the exact state. For our purposes the information you would need to retain to replay the game to its current state will help you establish the essential data. Now you can assess what each state and its transition looks like. If you are smart enough you will realize that once you have a given state of chess at that point you can technically calculate all the possible variations that will yield checkmate. This is not realistic as far as computation as this would be in polynomial time. When you look at an application or a system from a state machine perspective it is a very simple way to capture its essence.
The important detail is where the major logic should be defined. Each piece should have the ability in a given board return a list of all valid moves. Most of the information may be interpreted from the current state of the board and its pieces. Certain things like if you moved the king or not would not be evident since the king may be moved away and then returned to its inital location. We need to assume that a board may have rules and state. Like was the king moved or not, or is there a piece here or not. The game and its players have some rules and state. The color pieces of each player. Most importantly is the rules of each individual piece type.
For some of the attributes you may find yourself creating lots of boolean attributes to represent what appears to be property.
Don’t do the equivalency of creating a ton of columns in a single table. That is the opportunity to create proper and fitting classifications.
When I started working at a company they had a production database. They had no database schema defined. They didn’t even have a normal development environment. They would attempt to clean production data and populate the development database. One of the biggest issues was they would make database schema changes in development and then have no idea what they were missing in production. They were so far away from a modern day CI/CD engineering process. I looked around for different ways to solve this issue.
At one point in time I was contemplating building a solution from the ground up. The first approach I had been taking was to simply have a git repository that held the database DDL files. The challenge was dealing with possibly dirty systems that had been manually changed. Identifying the current state of the DB in question and if/how to update it to the newest version.
Typically I would have a production environment, a development environment, and a build/test environment. Depending on the size of the engineering team I would like each engineer to have their own development environment. The build/test environment is used when a build is occurring. I need to be able to update an existing environment, as well as create a new DB on the fly. Sometimes I will need to not only create or alter the database structure. At times fairly complex migrations are needed to adapt older data to the new structure. This can be a fickle and tricky process that cannot allow for error. Flyway has its community (free as in speech & beer) edition, as well as its professional edition which has a modest price tag attached to it. Two of the most appealing paid features are “undo” and “dry-run”. The undo feature does exactly what it sounds like. It can undo one or more steps of a migration. Generally if a migration will fail during a transaction the flyway can simply rollback the transaction. However, I’ve had many circumstances where the migration was successful but something else was not functioning as expected. Now I need to revert the code as well as the database.
I am most likely using ECS Fargate, or Elastic Container Service on AWS. With a CloudFormation template describing the environment and infrastructure. Whenever I would have an update of my Spring Boot application I would use the Git hash from the commit and tag my Docker container with it. This provides an easy way to directly link a commit with its built image. I would push the Docker images to ECR (Elastic Container Registry) which houses the Docker images. The CloudFormation stack would be updated with the new image hash. ECS is designed to ensure that the new version of the service is stable and healthy prior to standing down the previous version and directing traffic to the new instance. One big issue that I have yet to effectively deal with, and have a number of very simple ways to handle. In my SDLC there are no releases, when code has been fully tested it goes out to production. That often means that it may be rolled out during business hours. In many instances the product I would be dealing with is not limited to business hours, rather an all time expectation. You of course can have maintenance periods but that is less than ideal. What do you do with an updated database which corresponds to an updated POJO that maps the database schema to a object. With statically typed languages and preferred enterprise approach you are using type-safe domain objects. Now during this grace period of a few minutes you should have the old version functional that will gracefully switch over to the new version. What may end up happening is that the old or former version becomes invalid due to the database migration. Now you essentially need to
This has become especially important
I believe a reference to both Flyway and Liquibase I found Flyway and was extremely impressed. The other major contender was Liquibase.
]]>A truly modular system will enable you to “shove together” modules and the system will appropriately handle them. This was left quite ambiguous because depending on the type of components it is possible that in any given system you only may have a single instance. Like for instance a logger. If you have some experience with Java logging libraries you may find seen issues when more than one implementation is found on the classpath. Similarly, you may have issues with regular packages that don’t interact well together because they have conflicting dependency versions. Having the ability to have the system determine at runtime based on a whole bunch of priority parameters that impact the functionality. If you are familiar with Spring Boot you should be extremely familiar with this sort of flexibility. When you get used to that customization you get this feeling that you can do anything with your code. This functional capacity is an extension of traditional polymorphism. Having the ability to assume multiple traits of an interface is fairly limited when you pin down the code that is available. Creating your modules to be truly self contained is the basis of good enterprise architecture and the key to most problems you run into. The recent version of Java 9 takes this approach and improves some of the challenges. Providing clear definitions as to what the module requires and what it contains is what the new modularity functionality provides. It’s very nice, but you can accomplish a lot without that.
A jar is just a compressed archive with whatever content you put into it.
Traditionally utilizing a manifest was the way you had to specify if you want to directly invoke a jar what class should be invoked.
That is still of course the case. However, you can have a jar that only holds classes without any main class.
There is a great library that can facilitates scanning the classpath in addition to many other things like a jar sitting on a local or remote file-system.
This library is extremely fast because it reads the java class files interpreting the bytecode without actually loading the files.
Let’s say I have an enterprise system that connects event-driven applications.
I want to allow the user to be able to upload a new jar file to s3.
From that jar the system may dynamically load and unload modules and subscribe/unsubscribe to specific events.
With java I can dynamically pull the jar object.
While not everyone loves the ins and outs of the JVM classpath, the ability to dynamically load modules or executable code is an extremely valuable capability.
I’ve created a tic-tac-toe application that is available here. I specifically wrote this code to be as functional and procedural as possible. I wanted to make the design very “simple” and only focused on the simplest tic-tac-toe game. You can say there isn’t anything wrong with this code, it is well documented.
This is the board of a 3×3. This is how the indicies are numbered. They are zero index based.
0 1 2
3 4 5
6 7 8
0 1 2 3
4 5 6 7
8 9 10 11
12 13 14 15
0 1 2 3 4
5 6 7 8 9
10 11 12 13 14
15 16 17 18 19
20 21 22 23 24
The only configurable option is the size of the board. It defaults to a 3×3 board, but you can create the board with a different size.
The approach used for calculating if their is a win or a draw is not the most efficient method.
I decided to favor cleaner more readable code over efficiency that would be negligible.
In fact, unless the board were to be several thousands larger than a traditional board the difference would be minuscule. Let’s look at the getWinner() function:
public char getWinner() {
// Iterate through each winning algorithm
// For most of them then iterate for each row
for(int x=0; x < size; x++) {
char[] chars = getCells(WinningPath.HORIZONTAL, x);
char c = getCharIfAllSame(chars);
if(c != empty) {
return c;
}
chars = getCells(WinningPath.VERTICAL, x);
c = getCharIfAllSame(chars);
if(c != empty) {
return c;
}
}
char[] chars = getDiagonal1();
char c = getCharIfAllSame(chars);
if(c != empty) {
return c;
}
chars = getDiagonal2();
c = getCharIfAllSame(chars);
if(c != empty) {
return c;
}
return empty;
}
For both horizontal and vertical we iterate through each algorithm one time per dimension.
The other two calls are for the two diagonals.
The getCells(WinningPath path, Integer offset) call returns back an array of chars according to the specified algorithm.
Following that call the getCharIfAllSame(char[] chars) function is invoked to evaluate whether or not the returns chars are all the same or not.
These two steps make the code longer but much more flexible and easier to understand.
Here is the getCells() call. It’s a very simple dispatcher pattern.
public char[] getCells(WinningPath wp, int... args) {
char[] t = new char[size];
for(int x=0; x < size; x++) {
int c = 0;
switch(wp) {
case HORIZONTAL:
c = getRow(args[0], x);
break;
case VERTICAL:
c = getColumn(args[0], x);
break;
case DIAGONAL:
c = getDiagonal(args[0], x);
break;
}
t[x] = board[c];
}
return t;
}
The actual individual algorithm is broken down based on the strategy.
The getRow() function looks like this:
// Row 0 -> 0 1 2
// Row 1 -> 3 4 5
// Row 2 -> 6 7 8
public int getRow(int row, int offset) {
return offset + (row * size);
}
// Column 0 -> 0 3 6
// Column 1 -> 1 4 7
// Column 2 -> 2 5 8
public int getColumn(int column, int offset) {
return column + (size * offset);
}
public int getDiagonal(int diag, int offset) {
if(diag == 0) {
if(offset == 0) {
return 0;
} else {
return (size+1) * offset;
}
} else {
if(offset == 0) {
return size - 1;
} else {
return (size - 1) * (offset + 1);
}
}
}
This quite simply is a function that will return the index of the row cells for the inputted row and offset. This function will handle different sized boards, not just the standard 3×3.
I haven’t made the time to continue the more advanced version of this. I began working on a very generalized architecture. Even-though the implementation is not complete, I am very happy with the architecture thus far and know when the time is there to complete it, it will be very modular and powerful.
Let’s start looking at the major packages and their interfaces and classes of the oop package:
Turn.Iterator<Player>. Determines the initial Player and subsequent Player. Allows for games where the players would rotate who goes first.The first thing that was clear to me was that I wanted to define a Game.
public interface Game extends
Serializable,
TurnHistory,
GameOutcome {
UUID getId();
LocalDateTime getCreated();
LocalDateTime getUpdated();
Turn start();
void stop();
}
I thought about games and wanted to separate the game play from the rules and the state of the game.
Most games are turn-based. Meaning that one player goes and then another, etc. What defined the order of the turns or who goes first is something entirely different.
The TurnHistory interface is quite simple:
public interface TurnHistory {
List<Turn> getTurns();
}
It is a container to hold all references to a Game’s Turn.
public interface Turn<T extends Action> extends Serializable, Comparable<Turn> {
UUID getId();
LocalDateTime getCreated();
LocalDateTime getUpdated();
Optional<T> getAction();
Player getPlayer();
default boolean turnCompleted() {
return getAction().isPresent();
}
}
A Turn is created and updated when the Turn is acted or updated. A Turn has a reference to its defined Player and the Action if it has been invoked or not.
public interface Action<T extends Action> extends Serializable, Comparable<T> {
UUID getId();
LocalDateTime getCreated();
}
An Action is simply a defined entity that is created and uniquely defined.
With Tic-Tac-Toe or many BoardGame in mind I created a Move which is a type of Action.
public interface Move<T extends Move> extends Action<T> {
UUID getId();
Position getPosition();
Player getPlayer();
}
The Move interface adds the Position that the Player moved.
A general Position interface is:
public interface Position extends Serializable {
boolean isEmpty();
boolean isOccupied();
<T> T getOccupant();
<T> void setOccupant(T occupant);
void clearOccupant();
}
This is built on the premise that only a single occupant may occupy a Position at any given moment.
For Tic-Tac-Toe I have created a concrete class called TwoDimensionalPosition which is based on a traditional euclidian coordinate system.
The BoardGame interface extends the Game interface.
Of course the BoardGame interface also extends the Board interface which is actually a marker or empty interface.
I decided that a Board would be a generic entity on its own outside of the context of the Game.
Also, the Board doesn’t actually define its coordinates or game.
The TicTacToeBoard extends the BoardGame interface. The concrete class TwoDimensionalTicTacToeBoard extends the TicTacToeBoard.
This was specifically designed to handle a typical game of Tic-Tac-Toe.
Now let’s look at the TicTacToe class.
It extends the SequentialTurnBasedGame interface. Quite simply the TicTacToe implementation binds together the rules dictated by the WinningStrategy implementations.
The rest of the system functions with a publish/subscribe event model.
The idea is to generalize the system to enable listening for certain event types and react to them.
This approach makes it very easy to create custom rules.
I ran into the classic overthinking problem. I was making this project for instructional purposes and therefore had very flimsy requirements.
I wanted to allow for even complex games like realtime strategy games and the like.
I could easily “finish” this if I set some concrete restrictions, but it was challenging to correctly identify the exact nature of the interfaces.
The sequential part ensures that every turn occurs in order one after the other.
Traditional rules of Tic-Tac-Toe as far as I know doesn’t have a time limit on a turn.
I wanted it to be possible that a Turn should be capable of having a time limitation.
How would the game handle? It should be possible to say that the Turn was either forfeited or timed-out.
Ideally the model shouldn’t require changes to the base classes. Proper design should allow for the Turn to be modular enough.
Certain turn based games like card games or Catan have entire sets of logic that are subject to that turn.
We need a way to have nested turns that would separate the actions in the turn from the turn itself.
You see this can get very complex. My rule of thumb has been and always been if you are accurate enough to the reality you are almost never wrong.
This logic forced me to rethink a Turn and separate it from an Action. A Turn was a container for the current player.
I even forgot after some time why did the Action also have a Player getPlayer() method on its interface.
The idea is that the Action may be invoked by a different Player than the parent Turn.
Suffice to say this can get very complex. The major thing that is well designed is the pub/sub approach.
http://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html
]]>Cost is more than a number. It’s a mantra. Cost savings cannot be an afterthought. It must be designed and accounted for from the beginning. The nuance of this first law is that cost is not usually mentioned with requirements. The discussion of cost usually is only after things are design and deployed. I’ve heard of asking projects of how much will this cost. But I’ve never thought of making cost an actual requirement. In other words, it is not enough to be cost conscious. It is needed to go a step further and actually establish how much or little the product in question will cost to operate. This means we design around the cost not exceeding this value. Now we will need to factor this against the performance, scalability and resilience that we are expecting for this product.
The emphasis here is that there must be a clear and defined relationship between cost and business. That means that as the business grows your costs may grow. That is to be expected and should align properly. Cost is not expected in all circumstances to be fixed (unless it is). It is usually understood that costs will rise as different dimensions of usage increase. The word performance is very vague when we are dealing with the specifics of a system. If we are talking about the throughput, even that is too vague. The throughput must be discussed within the context of a volume of requests at one time. That means when we are talking about “how long it takes to process a request”, we need to factor in how many requests we are processing at a given time. The other important factor is how much “stuff” do we have in our data stores that might affect how long things take. If our request involves checking against the correlation of other existing transactions the sheer volume of existing transactions will heavily influence the duration of the call. So too, if we are expecting up to 100 simultaneous calls, or 100,000 simultaneous calls this will greatly affect the request duration. All of this is relevant when you are considering cost. In today’s “serverless” world, the ability to infinitely scale without having much or any provisioned resources can take the burden of upfront costs away. However, depending on what solution you are using for your data storage will deeply affect your ability to scale.
The business model might necessitate a certain SLA for requests. Ideally as your company and business grows the demand on resources and complexity will increase and ideally costs per unit will decrease. Obviously the overall cost will rise, but as you hit new cost thresholds you will ideally merit volume discounts on computing services.
The engineering cost is another that needs to factored in. As the complexity of a product grows the development costs and maintenance costs will rise. A simple system is cheap to develop. A complex one can be costly. So sometimes focusing on cutting costs for computing ends up costing a great deal more money for personnel and isn’t worth the expenditure. In my opinion nothing beats clean simple code. If you can hit your SLAs, don’t be greedy thinking that you will save big with pennies here and there. The sheer cost of engineering and maintenance on a complex system may not be worth it.
It is well known that there are no perfect systems or solutions. Every system has a balancing act of a myriad of factors. Cost comes in two flavors in the computer world. Cost is money and cost is time. In reality, they are one because computing costs ends up being all about money. If you are dealing with an algorithm like for compression or machine learning your approach often favors time over quality of the outputted result. Let’s look at compression its very simple. Today you can have a song that is encoded with a very high quality lossless encoding that is very large in size. Here you are preferring quality over size. Or you can have the humble MP3 that is decent quality and notably small in with respect to filesize. When MP3s came out in the early 90’s internet connection speeds were often dial-up and notoriously slow. The MP3 was a game changed because the sound quality was good and the file was easily to deliver.
Today, where everyone has a high speed internet connection, we don’t really need MP3s anymore. In architecture, we will make decisions like the MP3 often for well intended reasons. Only to soon find out that reason no longer applicable. A new technology comes out, or the nature of the request rate or data schema change in such a way making the architectural choices stale and outdated. You will always need to choose between several factors when designing a solution, and that rationale may not stand the test of time. With that said, the cost should adjust with those factors. The trade-offs for using MP3 over a lossless format is the time to transfer and the storage size. It needs to be understood what you are paying for and why. As times will change and your music streaming service updates, it might charge slightly more to accommodate for the higher operating costs of storing and streaming the lossless files.
No matter how much planning goes into a system there will always be unforeseen costs. The traffic is higher than expected, the runtime is longer than expected, the file size is larger than expected. Without visibility into the system it is impossible to be aware of how on target you may or may not be with respect to expected costs. Let us not forget the costs of management and personnel. Amazon is well known for having the ability to tag almost every resource out there so that you may effectively and easily known your costs. Knowing the costs of resources without their proper context is more or less useless. If you know your system costs $1,000 last month, and $1,500 the month prior, what is the rationale for that $500 difference is key. Seeing the correlation between your resource and personnel costs against the business is key. Let’s say that you have metrics that you can see how many incident tickets you have for a given component. Being able to detect that really the lower month of $1,000 was due to downtime because of several critical failures, would greatly inform your cost analysis. The more you know and the more dots you can connect the more you can nail down waste and over or under utilization.
Beyond merely monitoring components, the ability to easily tune and configure the cost versus power of a given component becomes a surefire way to save money. Having components separated into tiers of priority is an easy way to isolate what components may be tweaked with over time for cost savings. A component in a lower priority may be reduced in power when its need is lower. Such that you don’t need 100 nodes to process data if you are only using 2 at the time. The question of startup time comes in to play. What if a customer suddenly needs to run a large payload that will overwhelm our pool of nodes. Do we always run 100 nodes to accommodate for those occasions? You can be sure that AWS thinks about those questions. We all know that AWS Lambda is not actually infinitely scalable, despite us using the term. AWS must spend a lot of money and time coming up with proper projections on how many nodes to dedicate to handle bursts or surges in usage.
The idea that costs and cost-cutting must be justified via business impact is key. Cost-cutting can go too far when you find yourselves without the number of nodes needed to run your request in a given SLA. This is a juggling act that must allow for risk. A backup process that runs in a scheduled fashion. Running the process is integral, but running the process hourly versus twice daily may have drastic cost savings that may not be integral to the business needs.
The idea of tuning a product at small levels enables you to tweak parameters easily that may affect costs. Everyone knows a key in good software design is as much as possible parameterize your configuration enabling configuration without requiring a rebuild. To be able to tune your product in real time, see the effects and persist that configuration is a game changer. Being able to do that easily without rebuilding a product opens up your application to new modern possibilities. Especially today where you might be able to use an ML/AI model to attempt to tweak parameters and find a sweet spot where performance and cost are in perfect harmony.
If you are trying to optimize your costs and doing it properly it doesn’t happen in one day. Even the best designed systems may be improved over time as factors change or expected utilization differs from expected. This is built on Laws IV and V. You cannot cut costs without proper metrics, and beginning the process of reducing costs starts with tunable or configurable components that you may be able to adjust that affect performance and costs. Taking property x and turning it from 10 to 1 is not only ill-advised but wrong. The proper way of tweaking parameters is with a dummy environment where you can run controlled tests with varied parameters and evaluate the performance with those new settings. As mentioned earlier, today there are automated ways of doing this that might find harmony with ML/AI solutions that can help with these adjustments. When tweaking things manually don’t expect to go from spending $1,000 to $50 without breaking things. You may never be able to get under a certain cost and that may be the reality. Rewrites of certain components might be necessary beyond just tweaking the known configurable options. Breaking out components into smaller bite sized pieces that further determine if this function is run under the given circumstances are all minor ways to reduce milliseconds from task execution.
Variety is the spice of life. With technology the “tried and true” spirit can lead only too often to complacency and a lack of growth. As Werner concludes the idea of saying we are a “Java shop” is often the cause of a lack of innovation. Cost optimization, stems from both cutting down and trimming the fat as well as making the core product more powerful and robust with less. Let me give an example. Java is notorious for being a technology that is slow on cold starts. That means to get things going to need to wait until more usage where the application is properly loaded, and the system has tuned itself for optimizations. A recent new feature enables you to warm up the application and save it in that state, so you may be able to restart the application already nice toasty and warm. This dramatically changes the ability to use Java in a serverless capacity. This now takes a technology that was more or less unusable in serverless ecosystems and would require complete rewrites to take advantage of this new platform called serverless into a reality. The status quo is the enemy of innovation. The more innovation yields to better performance, and ultimately better cost savings. When you see the lifecycle of R&D to innovation and cost savings that goes back into R&D it’s a beautiful thing.
]]>