Our Services
Software Development
My development roots includes a very strong experience with the Perl
programming language, and some experience with Kotlin, PHP, C and
several over languages.
I can join your development team part or full-time and work on your
project, as well as help your team setup the development workflow,
your project infrastructure, review your code - one time or on an
on-going basis.
I can also review your code, architecture and infrastructure and
support your team on overcoming performance, scalability or resilience
issues you systems may have.
I can advise and support your team on choosing, maintaining, using
and optimizing relational databases - as MySql or Postgresql -
document based databases as MongoDb, data streaming systems - as Kafka
or AWS Kinesis - Kubernetes, Application servers as Tomcat or nginx,
monitoring systems as datadog, sentry, graphite, etc.
My development roots includes a very strong experience with the Perl programming language, and some experience with Kotlin, PHP, C and several over languages.
I can join your development team part or full-time and work on your project, as well as help your team setup the development workflow, your project infrastructure, review your code - one time or on an on-going basis.
I can also review your code, architecture and infrastructure and support your team on overcoming performance, scalability or resilience issues you systems may have.
I can advise and support your team on choosing, maintaining, using and optimizing relational databases - as MySql or Postgresql - document based databases as MongoDb, data streaming systems - as Kafka or AWS Kinesis - Kubernetes, Application servers as Tomcat or nginx, monitoring systems as datadog, sentry, graphite, etc.
Software Architecture
The architecture of your software system have a big impact in multiple
aspects of your project, from its scalability and resilience, to the
cost of operating it, to the ability of your team to change it.
A lot of different aspects of your project must be taken into
consideration when (re)designing the architecture of your system.
How big is your team?
While a smaller team will easily manage to work together in a monolith
without major conflicts, and can, generally, coordinate changes to
avoid conflicts, as the team grows, it becomes important to create
contracts between the team - apis and data streams are the two most
common ways to define those contracts.
Realtime vs Delayed
How important is the latency of your requests in your system? When
your client makes a request is it important to process it immediately
or can it be done a bit later? How much later? A few milliseconds? A
few seconds? Several minutes? Next day?
For most systems a mix of both is the best choice, but what needs to
be done synchronously and what can be postponed is not always obvious.
And how do you postpone it? A asynchronous task? A message queue? A
pubsub system?
Options, options, options. And quite often choosing the best
technology is not the most important factor - choosing a technology
that plays nicely with your team and your ecosystem - the programming
language, the databases, the cloud system, etc - can be equally
important.
Monolith vs Macro Services vs Micro Services vs …
What serves Netflix and Uber may not be the best option for your team.
While they have the people and money to invest in the needed
infrastructure and know how to handle a system with more independently
deployable components than the developer writing the code of those
component, do you?
Can you team handle the cascading failures that micro service based
systems are prone to have? Does your team have the time and know how
to setup mesh networking systems and circuit breakers to prevent them?
How much downtime can you business live with?
In 1998 I helped setup a couple of Disco setups. Disco was a bar/disco
POS system. The most interesting feature of Disco, for me, was that it
used a client/server architecture, but the clients could work
independently of the server being up.
A normal setup of Disco would have a bunch of computers (one in each
bar), each with their own UPS (battery), a central server where
ultimately all data was stored, which kept track of inventory and all
of that, but if the server was down, the POS computer would keep
registering sales, printing notes, getting money from their clients.
Generally, they didn’t care if the inventory was gone because if the
bartender was able to sell it was because there was some to sell.
When, eventually, the server come up and the POS was able to connect
to it, it would upload the sales, get updates on prices, etc.
Today we build a lot of system that assume that internet is fast and
reliable and that the server will always be there. Can your business
work with such assumptions?
Times change
And everything else changes with time. When you system was started
some assumption were made about how your business would work. As
time passes, some of those assumption are proven right, some need to
be adjusted. How implications does that have on your system?
And how can you transform the system that served your business so well
so far into the system your business needs today? Into the system that
your business will need to travel the road ahead?
And how do you change it while your clients keep coming in, while you
keep serving them?
I can Help
I have plenty of experience rebuilding systems while they keep
running, with minor disruptions.
I can help you team (re)design and (re)build your system in line with
your needs, while your business keeps flying always slightly higher,
always slightly faster.
The architecture of your software system have a big impact in multiple aspects of your project, from its scalability and resilience, to the cost of operating it, to the ability of your team to change it.
A lot of different aspects of your project must be taken into consideration when (re)designing the architecture of your system.
How big is your team?
While a smaller team will easily manage to work together in a monolith without major conflicts, and can, generally, coordinate changes to avoid conflicts, as the team grows, it becomes important to create contracts between the team - apis and data streams are the two most common ways to define those contracts.
Realtime vs Delayed
How important is the latency of your requests in your system? When your client makes a request is it important to process it immediately or can it be done a bit later? How much later? A few milliseconds? A few seconds? Several minutes? Next day?
For most systems a mix of both is the best choice, but what needs to be done synchronously and what can be postponed is not always obvious. And how do you postpone it? A asynchronous task? A message queue? A pubsub system?
Options, options, options. And quite often choosing the best technology is not the most important factor - choosing a technology that plays nicely with your team and your ecosystem - the programming language, the databases, the cloud system, etc - can be equally important.
Monolith vs Macro Services vs Micro Services vs …
What serves Netflix and Uber may not be the best option for your team. While they have the people and money to invest in the needed infrastructure and know how to handle a system with more independently deployable components than the developer writing the code of those component, do you?
Can you team handle the cascading failures that micro service based systems are prone to have? Does your team have the time and know how to setup mesh networking systems and circuit breakers to prevent them?
How much downtime can you business live with?
In 1998 I helped setup a couple of Disco setups. Disco was a bar/disco POS system. The most interesting feature of Disco, for me, was that it used a client/server architecture, but the clients could work independently of the server being up.
A normal setup of Disco would have a bunch of computers (one in each bar), each with their own UPS (battery), a central server where ultimately all data was stored, which kept track of inventory and all of that, but if the server was down, the POS computer would keep registering sales, printing notes, getting money from their clients.
Generally, they didn’t care if the inventory was gone because if the bartender was able to sell it was because there was some to sell. When, eventually, the server come up and the POS was able to connect to it, it would upload the sales, get updates on prices, etc.
Today we build a lot of system that assume that internet is fast and reliable and that the server will always be there. Can your business work with such assumptions?
Times change
And everything else changes with time. When you system was started some assumption were made about how your business would work. As time passes, some of those assumption are proven right, some need to be adjusted. How implications does that have on your system?
And how can you transform the system that served your business so well so far into the system your business needs today? Into the system that your business will need to travel the road ahead?
And how do you change it while your clients keep coming in, while you keep serving them?
I can Help
I have plenty of experience rebuilding systems while they keep running, with minor disruptions.
I can help you team (re)design and (re)build your system in line with your needs, while your business keeps flying always slightly higher, always slightly faster.
Business Continuity
Every computer fails one day. One of this days it is going to be one
that is critical for your business. Is your team ready for that day?
Does your database have backups? Is your site running on redundant
systems? Do you know when some part of your system fails? Can your
team say how and why it failed?
Backups, monitoring, redundancy are important parts of a business
continuity plan. I can review or help you design your plan and test it
out without impacting your production systems.
While it is almost impossible to avoid that systems fail, with proper
planing most of those failures will have minimal impact on your
business, and when downtime is unavoidable, its time and impact can be
reduced by having the right backups and redundancies in place.
Every computer fails one day. One of this days it is going to be one that is critical for your business. Is your team ready for that day?
Does your database have backups? Is your site running on redundant systems? Do you know when some part of your system fails? Can your team say how and why it failed?
Backups, monitoring, redundancy are important parts of a business continuity plan. I can review or help you design your plan and test it out without impacting your production systems.
While it is almost impossible to avoid that systems fail, with proper planing most of those failures will have minimal impact on your business, and when downtime is unavoidable, its time and impact can be reduced by having the right backups and redundancies in place.