Category Archives: Lifestream

Sometimes you do need Kubernetes! But how should you decide?

At RisingStack, we help companies to adopt cloud-native technologies, or if they have already done so, to get the most mileage out of them.

Recently, I've been invited to Google DevFest to deliver a presentation on our experiences working with Kubernetes.

Below I talk about an online learning and streaming platform where the decision to use Kubernetes has been contested both internally and externally since the beginning of its development.

The application and its underlying infrastructure were designed to meet the needs of the regulations of several countries:

  • The app should be able to run on-premises, so students’ data could never leave a given country. Also, the app had to be available as a SaaS product as well.

  • It can be deployed as a single-tenant system where a business customer only hosts one instance serving a handful of users, but some schools could have hundreds of users.

  • Or it can be deployed as a multi-tenant system where the client is e.g. a government and needs to serve thousands of schools and millions of users.

The application itself was developed by multiple, geographically scattered teams, thus a Microservices architecture was justified, but both the distributed system and the underlying infrastructure seemed to be an overkill when we considered the fact that during the product's initial entry, most of its customers needed small instances.

Was Kubernetes suited for the job, or was it an overkill? Did our client really need Kubernetes?

Let’s figure it out.

(Feel free to check out the video presentation, or the extended article version below!)

Let's talk a bit about Kubernetes itself!

Kubernetes is an open-source container orchestration engine that has a vast ecosystem. If you run into any kind of problem, there's probably a library somewhere on the internet that already solves it.

But Kubernetes also has a daunting learning curve, and initially, it's pretty complex to manage. Cloud ops / infrastructure engineering is a complex and big topic in and of itself.

Kubernetes does not really mask away the complexity from you, but plunges you into deep water as it merely gives you a unified control plane to handle all those moving parts that you need to care about in the cloud.

So, if you're just starting out right now, then it's better to start with small things and not with the whole package straight away! First, deploy a VM in the cloud. Use some PaaS or FaaS solutions to play around with one of your apps. It will help you gradually build up the knowledge you need on the journey.

So you want to decide if Kubernetes is for you.

First and foremost, Kubernetes is for you if you work with containers! (It kinda speaks for itself for a container orchestration system). But you should also have more than one service or instance.

kubernetes-is-for-you-if

Kubernetes makes sense when you have a huge microservice architecture, or you have dedicated instances per tenant having a lot of tenants as well.

Also, your services should be stateless, and your state should be stored in databases outside of the cluster. Another selling point of Kubernetes is the fine gradient control over the network.

And, maybe the most common argument for using Kubernetes is that it provides easy scalability.

Okay, and now let's take a look at the flip side of it.

Kubernetes is not for you if you don't need scalability!

If your services rely heavily on disks, then you should think twice if you want to move to Kubernetes or not. Basically, one disk can only be attached to a single node, so all the services need to reside on that one node. Therefore you lose node auto-scaling, which is one of the biggest selling points of Kubernetes.

For similar reasons, you probably shouldn't use k8s if you don't host your infrastructure in the public cloud. When you run your app on-premises, you need to buy the hardware beforehand and you cannot just conjure machines out of thin air. So basically, you also lose node auto-scaling, unless you're willing to go hybrid cloud and bleed over some of your excess load by spinning up some machines in the public cloud.

kubernetes-is-not-for-you-if

If you have a monolithic application that serves all your customers and you need some scaling here and there, then cloud service providers can handle it for you with autoscaling groups.

There is really no need to bring in Kubernetes for that.

Let's see our Kubernetes case-study!

Maybe it's a little bit more tangible if we talk about an actual use case, where we had to go through the decision making process.

online-learning-platform-kubernetes

Online Learning Platform is an application that you could imagine as if you took your classroom and moved it to the internet.

You can have conference calls. You can share files as handouts, you can have a whiteboard, and you can track the progress of your students.

This project started during the first wave of the lockdowns around March, so one thing that we needed to keep in mind is that time to market was essential.

In other words: we had to do everything very, very quickly!

This product targets mostly schools around Europe, but it is now used by corporations as well.

So, we're talking about millions of users from the point we go to the market.

The product needed to run on-premise, because one of the main targets were governments.

Initially, we were provided with a proposed infrastructure where each school would have its own VM, and all the services and all the databases would reside in those VMs.

Handling that many virtual machines, properly handling rollouts to those, and monitoring all of them sounded like a nightmare to begin with. Especially if we consider the fact that we only had a couple of weeks to go live.

After studying the requirements and the proposal, it was time to call the client to..

Discuss the proposed infrastructure.

So the conversation was something like this:

  • "Hi guys, we would prefer to go with Kubernetes because to handle stuff at that scale, we would need a unified control plane that Kubernetes gives us."

  • "Yeah, sure, go for it."

And we were happy, but we still had a couple of questions:

  • "Could we, by any chance, host it on the public cloud?"

  • "Well, no, unfortunately. We are negotiating with European local governments and they tend to be squeamish about sending their data to the US. "

Okay, anyways, we can figure something out...

Okay, crap! But we still needed to talk to the developers so all was not lost.

Let's call the developers!

It turned out that what we were dealing with was an usual microservice-based architecture, which consisted of a lot of services talking over HTTP and messaging queues.

Each service had its own database, and most of them stored some files in Minio.

kubernetes-app-architecture

In case you don't know it, Minio is an object storage system that implements the S3 API.

Now that we knew the fine-grained architectural layout, we gathered a few more questions:

  • "Okay guys, can we move all the files to Minio?"

  • "Yeah, sure, easy peasy."

So, we were happy again, but there was still another problem, so we had to call the hosting providers:

  • "Hi guys, do you provide hosted Kubernetes?"

  • "Oh well, at this scale, we can manage to do that!"

So, we were happy again, but..

Just to make sure, we wanted to run the numbers!

Our target was to be able to run 60 000 schools on the platform in the beginning, so we had to see if our plans lined up with our limitations!

We shouldn't have more than 150 000 total pods!

10 (pod/tenant) times 6000 tenants is 60 000 Pods. We're good!

We shouldn't have more than 300 000 total containers!

It's one container per pod, so we're still good.

We shouldn't have more than 100 pods per node and no more than 5 000 nodes.

Well, what we have is 60 000 pods over 100 pod per node. That's already 6 000 nodes, and that's just the initial rollout, so we're already over our 5 000 nodes limit.

kubernetes-limitations

Okay, well... Crap!

But, is there a solution to this?

Sure, it's federation!

We could federate our Kubernetes clusters..

..and overcome these limitations.

We have worked with federated systems before, so Kubernetes surely provides something for that, riiight? Well yeah, it does... kind of.

It's the stable Federation v1 API, which is sadly deprecated.

kubernetes-federation-v1

Then we saw that Kubernetes Federation v2 is on the way!

It was still in alpha at the time when we were dealing with this issue, but the GitHub page said it was rapidly moving towards beta release. By taking a look at the releases page we realized that it had been overdue by half a year by then.

Since we only had a short period of time to pull this off, we really didn't want to live that much on the edge.

So what could we do? We could federate by hand! But what does that mean?

In other words: what could have been gained by using KubeFed?

Having a lot of services would have meant that we needed a federated Prometheus and Logging (be it Graylog or ELK) anyway. So the two remaining aspects of the system were rollout / tenant generation, and manual intervention.

Manual intervention is tricky. To make it easy, you need a unified control plane where you can eyeball and modify anything. We could have built a custom one that gathers all information from the clusters and proxies all requests to each of them. However, that would have meant a lot of work, which we just did not have the time for. And even if we had the time to do it, we would have needed to conduct a cost/benefit analysis on it.

The main factor in the decision if you need a unified control plane for everything is scale, or in other words, the number of different control planes to handle.

The original approach would have meant 6000 different planes. That’s just way too much to handle for a small team. But if we could bring it down to 20 or so, that could be bearable. In that case, all we need is an easy mind map that leads from services to their underlying clusters. The actual route would be something like:

Service -> Tenant (K8s Namespace) -> Cluster.

The Service -> Namespace mapping is provided by Kubernetes, so we needed to figure out the Namespace -> Cluster mapping.

This mapping is also necessary to reduce the cognitive overhead and time of digging around when an outage may happen, so it needs to be easy to remember, while having to provide a more or less uniform distribution of tenants across Clusters. The most straightforward way seemed to be to base it on Geography. I’m the most familiar with Poland’s and Hungary’s Geography, so let’s take them as an example.

Poland comprises 16 voivodeships, while Hungary comprises 19 counties as main administrative divisions. Each country’s capital stands out in population, so they have enough schools to get a cluster on their own. Thus it only makes sense to create clusters for each division plus the capital. That gives us 17 or 20 clusters.

So if we get back to our original 60 000 pods, and 100 pod / tenant limitation, we can see that 2 clusters are enough to host them all, but that leaves us no room for either scaling or later expansions. If we spread them across 17 clusters - in the case of Poland for example - that means we have around 3.500 pods / cluster and 350 nodes, which is still manageable.

This could be done in a similar fashion for any European country, but still needs some architecting when setting up the actual infrastructure. And when KubeFed becomes available (and somewhat battle tested) we can easily join these clusters into one single federated cluster.

Great, we have solved the problem of control planes for manual intervention. The only thing left was handling rollouts..

gitops-kubernetes-federation

As I mentioned before, several developer teams had been working on the services themselves, and each of them already had their own Gitlab repos and CIs. They already built their own Docker images, so we simply needed a place to gather them all, and roll them out to Kubernetes. So we created a GitOps repo where we stored the helm charts and set up a GitLab CI to build the actual releases, then deploy them.

From here on, it takes a simple loop over the clusters to update the services when necessary.

The other thing we needed to solve was tenant generation.

It was easy as well, because we just needed to create a CLI tool which could be set up by providing the school's name, and its county or state.

tenant-generation-kubernetes

That's going to designate its target cluster, and then push it to our Gitops repo, and that basically triggers the same rollout as new versions.

We were almost good to go, but there was still one problem: on-premises.

Although our hosting providers turned into some kind of public cloud (or something we can think of as public clouds), we were also targeting companies who want to educate their employees.

Huge corporations - like a Bank - are just as squeamish about sending their data out to the public internet as governments, if not more..

So we needed to figure out a way to host this on servers within vaults completely separated from the public internet.

kubespray

In this case, we had two main modes of operation.

  • One is when a company just wanted a boxed product and they didn't really care about scaling it.

  • And the other one was where they expected it to be scaled, but they were prepared to handle this.

In the second case, it was kind of a bring your own database scenario, so you could set up the system in a way that we were going to connect to your database.

And in the other case, what we could do is to package everything — including databases — in one VM, in one Kubernetes cluster. But! I just wrote above that you probably shouldn't use disks and shouldn't have databases within your cluster, right?

However, in that case, we already had a working infrastructure.

Kubernetes provided us with infrastructure as code already, so it only made sense to use that as a packaging tool as well, and use Kubespray to just spray it to our target servers.

It wasn't a problem to have disks and DBs within our cluster because the target were companies that didn't want to scale it anyway.

So it's not about scaling. It is mostly about packaging!

Previously I told you, that you probably don't want to do this on-premises, and this is still right! If that's your main target, then you probably shouldn't go with Kubernetes.

However, as our main target was somewhat of a public cloud, it wouldn't have made sense to just recreate the whole thing - basically create a new product in a sense - for these kinds of servers.

So as it is kind of a spin-off, it made sense here as well as a packaging solution.

Basically, I've just given you a bullet point list to help you determine whether Kubernetes is for you or not, and then I just tore it apart and threw it into a basket.

And the reason for this is - as I also mentioned:

Cloud ops is difficult!

There aren't really one-size-fits-all solutions, so basing your decision on checklists you see on the internet is definitely not a good idea.

We've seen that a lot of times where companies adopt Kubernetes because it seems to fit, but when they actually start working with it, it turns out to be an overkill.

If you want to save yourself about a year or two of headache, it's a lot better to first ask an expert, and just spend a couple of hours or days going through your use cases, discussing those and save yourself that year of headache.

In case you're thinking about adopting Kubernetes, or getting the most out of it, don't hesitate to reach out to us at [email protected], or by using the contact form below!

Sometimes you do need Kubernetes! But how should you decide?

At RisingStack, we help companies to adopt cloud-native technologies, or if they have already done so, to get the most mileage out of them.

Recently, I've been invited to Google DevFest to deliver a presentation on our experiences working with Kubernetes.

Below I talk about an online learning and streaming platform where the decision to use Kubernetes has been contested both internally and externally since the beginning of its development.

The application and its underlying infrastructure were designed to meet the needs of the regulations of several countries:

  • The app should be able to run on-premises, so students’ data could never leave a given country. Also, the app had to be available as a SaaS product as well.

  • It can be deployed as a single-tenant system where a business customer only hosts one instance serving a handful of users, but some schools could have hundreds of users.

  • Or it can be deployed as a multi-tenant system where the client is e.g. a government and needs to serve thousands of schools and millions of users.

The application itself was developed by multiple, geographically scattered teams, thus a Microservices architecture was justified, but both the distributed system and the underlying infrastructure seemed to be an overkill when we considered the fact that during the product's initial entry, most of its customers needed small instances.

Was Kubernetes suited for the job, or was it an overkill? Did our client really need Kubernetes?

Let’s figure it out.

(Feel free to check out the video presentation, or the extended article version below!)

Let's talk a bit about Kubernetes itself!

Kubernetes is an open-source container orchestration engine that has a vast ecosystem. If you run into any kind of problem, there's probably a library somewhere on the internet that already solves it.

But Kubernetes also has a daunting learning curve, and initially, it's pretty complex to manage. Cloud ops / infrastructure engineering is a complex and big topic in and of itself.

Kubernetes does not really mask away the complexity from you, but plunges you into deep water as it merely gives you a unified control plane to handle all those moving parts that you need to care about in the cloud.

So, if you're just starting out right now, then it's better to start with small things and not with the whole package straight away! First, deploy a VM in the cloud. Use some PaaS or FaaS solutions to play around with one of your apps. It will help you gradually build up the knowledge you need on the journey.

So you want to decide if Kubernetes is for you.

First and foremost, Kubernetes is for you if you work with containers! (It kinda speaks for itself for a container orchestration system). But you should also have more than one service or instance.

kubernetes-is-for-you-if

Kubernetes makes sense when you have a huge microservice architecture, or you have dedicated instances per tenant having a lot of tenants as well.

Also, your services should be stateless, and your state should be stored in databases outside of the cluster. Another selling point of Kubernetes is the fine gradient control over the network.

And, maybe the most common argument for using Kubernetes is that it provides easy scalability.

Okay, and now let's take a look at the flip side of it.

Kubernetes is not for you if you don't need scalability!

If your services rely heavily on disks, then you should think twice if you want to move to Kubernetes or not. Basically, one disk can only be attached to a single node, so all the services need to reside on that one node. Therefore you lose node auto-scaling, which is one of the biggest selling points of Kubernetes.

For similar reasons, you probably shouldn't use k8s if you don't host your infrastructure in the public cloud. When you run your app on-premises, you need to buy the hardware beforehand and you cannot just conjure machines out of thin air. So basically, you also lose node auto-scaling, unless you're willing to go hybrid cloud and bleed over some of your excess load by spinning up some machines in the public cloud.

kubernetes-is-not-for-you-if

If you have a monolithic application that serves all your customers and you need some scaling here and there, then cloud service providers can handle it for you with autoscaling groups.

There is really no need to bring in Kubernetes for that.

Let's see our Kubernetes case-study!

Maybe it's a little bit more tangible if we talk about an actual use case, where we had to go through the decision making process.

online-learning-platform-kubernetes

Online Learning Platform is an application that you could imagine as if you took your classroom and moved it to the internet.

You can have conference calls. You can share files as handouts, you can have a whiteboard, and you can track the progress of your students.

This project started during the first wave of the lockdowns around March, so one thing that we needed to keep in mind is that time to market was essential.

In other words: we had to do everything very, very quickly!

This product targets mostly schools around Europe, but it is now used by corporations as well.

So, we're talking about millions of users from the point we go to the market.

The product needed to run on-premise, because one of the main targets were governments.

Initially, we were provided with a proposed infrastructure where each school would have its own VM, and all the services and all the databases would reside in those VMs.

Handling that many virtual machines, properly handling rollouts to those, and monitoring all of them sounded like a nightmare to begin with. Especially if we consider the fact that we only had a couple of weeks to go live.

After studying the requirements and the proposal, it was time to call the client to..

Discuss the proposed infrastructure.

So the conversation was something like this:

  • "Hi guys, we would prefer to go with Kubernetes because to handle stuff at that scale, we would need a unified control plane that Kubernetes gives us."

  • "Yeah, sure, go for it."

And we were happy, but we still had a couple of questions:

  • "Could we, by any chance, host it on the public cloud?"

  • "Well, no, unfortunately. We are negotiating with European local governments and they tend to be squeamish about sending their data to the US. "

Okay, anyways, we can figure something out...

Okay, crap! But we still needed to talk to the developers so all was not lost.

Let's call the developers!

It turned out that what we were dealing with was an usual microservice-based architecture, which consisted of a lot of services talking over HTTP and messaging queues.

Each service had its own database, and most of them stored some files in Minio.

kubernetes-app-architecture

In case you don't know it, Minio is an object storage system that implements the S3 API.

Now that we knew the fine-grained architectural layout, we gathered a few more questions:

  • "Okay guys, can we move all the files to Minio?"

  • "Yeah, sure, easy peasy."

So, we were happy again, but there was still another problem, so we had to call the hosting providers:

  • "Hi guys, do you provide hosted Kubernetes?"

  • "Oh well, at this scale, we can manage to do that!"

So, we were happy again, but..

Just to make sure, we wanted to run the numbers!

Our target was to be able to run 60 000 schools on the platform in the beginning, so we had to see if our plans lined up with our limitations!

We shouldn't have more than 150 000 total pods!

10 (pod/tenant) times 6000 tenants is 60 000 Pods. We're good!

We shouldn't have more than 300 000 total containers!

It's one container per pod, so we're still good.

We shouldn't have more than 100 pods per node and no more than 5 000 nodes.

Well, what we have is 60 000 pods over 100 pod per node. That's already 6 000 nodes, and that's just the initial rollout, so we're already over our 5 000 nodes limit.

kubernetes-limitations

Okay, well... Crap!

But, is there a solution to this?

Sure, it's federation!

We could federate our Kubernetes clusters..

..and overcome these limitations.

We have worked with federated systems before, so Kubernetes surely provides something for that, riiight? Well yeah, it does... kind of.

It's the stable Federation v1 API, which is sadly deprecated.

kubernetes-federation-v1

Then we saw that Kubernetes Federation v2 is on the way!

It was still in alpha at the time when we were dealing with this issue, but the GitHub page said it was rapidly moving towards beta release. By taking a look at the releases page we realized that it had been overdue by half a year by then.

Since we only had a short period of time to pull this off, we really didn't want to live that much on the edge.

So what could we do? We could federate by hand! But what does that mean?

In other words: what could have been gained by using KubeFed?

Having a lot of services would have meant that we needed a federated Prometheus and Logging (be it Graylog or ELK) anyway. So the two remaining aspects of the system were rollout / tenant generation, and manual intervention.

Manual intervention is tricky. To make it easy, you need a unified control plane where you can eyeball and modify anything. We could have built a custom one that gathers all information from the clusters and proxies all requests to each of them. However, that would have meant a lot of work, which we just did not have the time for. And even if we had the time to do it, we would have needed to conduct a cost/benefit analysis on it.

The main factor in the decision if you need a unified control plane for everything is scale, or in other words, the number of different control planes to handle.

The original approach would have meant 6000 different planes. That’s just way too much to handle for a small team. But if we could bring it down to 20 or so, that could be bearable. In that case, all we need is an easy mind map that leads from services to their underlying clusters. The actual route would be something like:

Service -> Tenant (K8s Namespace) -> Cluster.

The Service -> Namespace mapping is provided by Kubernetes, so we needed to figure out the Namespace -> Cluster mapping.

This mapping is also necessary to reduce the cognitive overhead and time of digging around when an outage may happen, so it needs to be easy to remember, while having to provide a more or less uniform distribution of tenants across Clusters. The most straightforward way seemed to be to base it on Geography. I’m the most familiar with Poland’s and Hungary’s Geography, so let’s take them as an example.

Poland comprises 16 voivodeships, while Hungary comprises 19 counties as main administrative divisions. Each country’s capital stands out in population, so they have enough schools to get a cluster on their own. Thus it only makes sense to create clusters for each division plus the capital. That gives us 17 or 20 clusters.

So if we get back to our original 60 000 pods, and 100 pod / tenant limitation, we can see that 2 clusters are enough to host them all, but that leaves us no room for either scaling or later expansions. If we spread them across 17 clusters - in the case of Poland for example - that means we have around 3.500 pods / cluster and 350 nodes, which is still manageable.

This could be done in a similar fashion for any European country, but still needs some architecting when setting up the actual infrastructure. And when KubeFed becomes available (and somewhat battle tested) we can easily join these clusters into one single federated cluster.

Great, we have solved the problem of control planes for manual intervention. The only thing left was handling rollouts..

gitops-kubernetes-federation

As I mentioned before, several developer teams had been working on the services themselves, and each of them already had their own Gitlab repos and CIs. They already built their own Docker images, so we simply needed a place to gather them all, and roll them out to Kubernetes. So we created a GitOps repo where we stored the helm charts and set up a GitLab CI to build the actual releases, then deploy them.

From here on, it takes a simple loop over the clusters to update the services when necessary.

The other thing we needed to solve was tenant generation.

It was easy as well, because we just needed to create a CLI tool which could be set up by providing the school's name, and its county or state.

tenant-generation-kubernetes

That's going to designate its target cluster, and then push it to our Gitops repo, and that basically triggers the same rollout as new versions.

We were almost good to go, but there was still one problem: on-premises.

Although our hosting providers turned into some kind of public cloud (or something we can think of as public clouds), we were also targeting companies who want to educate their employees.

Huge corporations - like a Bank - are just as squeamish about sending their data out to the public internet as governments, if not more..

So we needed to figure out a way to host this on servers within vaults completely separated from the public internet.

kubespray

In this case, we had two main modes of operation.

  • One is when a company just wanted a boxed product and they didn't really care about scaling it.

  • And the other one was where they expected it to be scaled, but they were prepared to handle this.

In the second case, it was kind of a bring your own database scenario, so you could set up the system in a way that we were going to connect to your database.

And in the other case, what we could do is to package everything — including databases — in one VM, in one Kubernetes cluster. But! I just wrote above that you probably shouldn't use disks and shouldn't have databases within your cluster, right?

However, in that case, we already had a working infrastructure.

Kubernetes provided us with infrastructure as code already, so it only made sense to use that as a packaging tool as well, and use Kubespray to just spray it to our target servers.

It wasn't a problem to have disks and DBs within our cluster because the target were companies that didn't want to scale it anyway.

So it's not about scaling. It is mostly about packaging!

Previously I told you, that you probably don't want to do this on-premises, and this is still right! If that's your main target, then you probably shouldn't go with Kubernetes.

However, as our main target was somewhat of a public cloud, it wouldn't have made sense to just recreate the whole thing - basically create a new product in a sense - for these kinds of servers.

So as it is kind of a spin-off, it made sense here as well as a packaging solution.

Basically, I've just given you a bullet point list to help you determine whether Kubernetes is for you or not, and then I just tore it apart and threw it into a basket.

And the reason for this is - as I also mentioned:

Cloud ops is difficult!

There aren't really one-size-fits-all solutions, so basing your decision on checklists you see on the internet is definitely not a good idea.

We've seen that a lot of times where companies adopt Kubernetes because it seems to fit, but when they actually start working with it, it turns out to be an overkill.

If you want to save yourself about a year or two of headache, it's a lot better to first ask an expert, and just spend a couple of hours or days going through your use cases, discussing those and save yourself that year of headache.

In case you're thinking about adopting Kubernetes, or getting the most out of it, don't hesitate to reach out to us at [email protected], or by using the contact form below!

Don’t Become A Tech Stack Prisoner

Hidden questions to ask yourself before adding a tool to your tech stack.

The silhouette of a person standing behind jail bars and a curious white dove flying by on the other side.
Source

As a busy marketing consultant, I meet with too many tech stack prisoners.

The biggest problems I see:

  • The tool is cookie-cutter.
  • The tool bottle-necks growth.
  • The tool is based on ancient tech.

A modern tech stack should take care of the dirty clockwork for you — not be the dirty clockwork.

It doesn’t matter if it looks like a newfangled Ferrari from the outside if what’s under the hood is actually 1995 Honda Civic parts.

What I see way too often is a CEO handing off all tech stack responsibility to the CTO without knowing a thing about the limitations.

Many of these CTOs recommend a “universal” tech stack.

I probably don’t have to tell you this, but if a CTO walks in the door telling you to use a “universal” tech stack — you should probably look for a new CTO.

  • Every startup has different needs.
  • A universal tech stack doesn’t exist.

The real reason many CTOs don’t want to switch to more modern solutions is likely because they’ve been using the same dusty stack for years and they don’t have the balls to do some learning.

Before trusting anyone to pour new tools like cereal into your tech stack ask yourself the following questions.

Does the tool scale?

Look for tools that grow with you.

The same tech stack that brought you from A to B will not always bring you from B to C. And that’s okay for little things, but you don’t want to be migrating your payment gateway or database every 6 months for example.

The best tools to add to your stack are those that support little dreams and big dreams. Stripe is a brilliant example of a tool that is modular enough to do just that. Whether you’re just starting out or if people call your brand a Unicorn — Stripe grows with you.

Does the tool create a better user experience?

A chainsaw is cool.

But cutting a chicken with it is a bloody mess.

Whether the tool is seen by your customers or by your team, it needs to make their lives easier — not harder. It also shouldn’t take a Ph.D. to master.

Not sure if a tool is user-friendly or not?

Look at the interface without clicking around.

  • If you intuitively know what it does, it’s user-friendly.
  • If you don’t it’s probably not that user-friendly.

Does the tool allow you to pivot fast?

Say you want to do a full rebrand tomorrow with a:

  • New name
  • New logo
  • New fonts
  • New colors
  • New tone

How long will it take to completely turn your brand upside down?

With the right tech stack, it should—at least technically — be possible within 24 hours.

Does the tool allow you to act on customer data?

Many tech stacks show data.

Few actually allow you to act on that data.

Instead of just showing you the problem areas, does the tool actually help you fix them, or is it just data C-suite executives use to brag about on the golf course?

The best tools allow you to see, fix, and prevent problems.

Does the tool sync in real-time with the rest of your tech stack?

Latency is real.

Just ask the lady who booked a seat in the movie theatre online while the man who chews popcorn like a hippo booked that exact seat at the POS counter for Jurassic World.

There is no more excuse not to have real-time syncing.

If a customer gives her email on the live chat on your website, the data needs to be synced seamlessly to your CRM. If a customer made an in-app purchase, inventory data needs to instantly update stock on your website through a real-time database.

A 5-second latency might not seem crazy at the beginning, but before you know it, you’re sitting with a massive problem.

Does the tool have (friendly) cross-channel API, Webhook, and Zapier integrations?

Nobody likes to spend hours going through terrible API documentation.

And no marketing team wants to wait for some nocturnal back-end wizard to finally crack the code that connects one tool with another.

A Zapier connection gets the ship moving — at least until the back-end gods responded to the nocturnal creature’s pleas.

Does the tool have a supportive community around it?

There’s nothing worse than having to search every inch of the internet not to be able to find the answer you’re looking for.

Does the tool allow for custom experiences or is it cookie-cutter?

Some tools may look pretty, but they are cookie-cutter.

Shopify is an example that comes to mind.

Do you really with your online store to look like everyone else’s? If not you better have a brilliant team of developers at hand to update the living heck out of every experience.

Your tech stack should allow you to stand out from the noise.

Does the tool use growing or aging technology?

Open Google Trends.

Type in the tool/technology’s name.

  • If interest is growing, that’s a good sign.
  • If interest is fading, you probably should look at why it’s losing market share.

I find that there’s usually a new competitor making life a little easier.

You don’t want to look back in 5 years sitting with ancient tech without updated support.

If I can leave you with one final piece of advice, make sure every tool you use allows you to seamlessly migrate when you decide to move on in the future.

I’m curious, what’s in your tech stack for:

  • Project management
  • Marketing/CRM
  • Backend/CMS
  • Frontend

Adblock test (Why?)

Don’t Become A Tech Stack Prisoner

Hidden questions to ask yourself before adding a tool to your tech stack.

The silhouette of a person standing behind jail bars and a curious white dove flying by on the other side.
Source

As a busy marketing consultant, I meet with too many tech stack prisoners.

The biggest problems I see:

  • The tool is cookie-cutter.
  • The tool bottle-necks growth.
  • The tool is based on ancient tech.

A modern tech stack should take care of the dirty clockwork for you — not be the dirty clockwork.

It doesn’t matter if it looks like a newfangled Ferrari from the outside if what’s under the hood is actually 1995 Honda Civic parts.

What I see way too often is a CEO handing off all tech stack responsibility to the CTO without knowing a thing about the limitations.

Many of these CTOs recommend a “universal” tech stack.

I probably don’t have to tell you this, but if a CTO walks in the door telling you to use a “universal” tech stack — you should probably look for a new CTO.

  • Every startup has different needs.
  • A universal tech stack doesn’t exist.

The real reason many CTOs don’t want to switch to more modern solutions is likely because they’ve been using the same dusty stack for years and they don’t have the balls to do some learning.

Before trusting anyone to pour new tools like cereal into your tech stack ask yourself the following questions.

Does the tool scale?

Look for tools that grow with you.

The same tech stack that brought you from A to B will not always bring you from B to C. And that’s okay for little things, but you don’t want to be migrating your payment gateway or database every 6 months for example.

The best tools to add to your stack are those that support little dreams and big dreams. Stripe is a brilliant example of a tool that is modular enough to do just that. Whether you’re just starting out or if people call your brand a Unicorn — Stripe grows with you.

Does the tool create a better user experience?

A chainsaw is cool.

But cutting a chicken with it is a bloody mess.

Whether the tool is seen by your customers or by your team, it needs to make their lives easier — not harder. It also shouldn’t take a Ph.D. to master.

Not sure if a tool is user-friendly or not?

Look at the interface without clicking around.

  • If you intuitively know what it does, it’s user-friendly.
  • If you don’t it’s probably not that user-friendly.

Does the tool allow you to pivot fast?

Say you want to do a full rebrand tomorrow with a:

  • New name
  • New logo
  • New fonts
  • New colors
  • New tone

How long will it take to completely turn your brand upside down?

With the right tech stack, it should—at least technically — be possible within 24 hours.

Does the tool allow you to act on customer data?

Many tech stacks show data.

Few actually allow you to act on that data.

Instead of just showing you the problem areas, does the tool actually help you fix them, or is it just data C-suite executives use to brag about on the golf course?

The best tools allow you to see, fix, and prevent problems.

Does the tool sync in real-time with the rest of your tech stack?

Latency is real.

Just ask the lady who booked a seat in the movie theatre online while the man who chews popcorn like a hippo booked that exact seat at the POS counter for Jurassic World.

There is no more excuse not to have real-time syncing.

If a customer gives her email on the live chat on your website, the data needs to be synced seamlessly to your CRM. If a customer made an in-app purchase, inventory data needs to instantly update stock on your website through a real-time database.

A 5-second latency might not seem crazy at the beginning, but before you know it, you’re sitting with a massive problem.

Does the tool have (friendly) cross-channel API, Webhook, and Zapier integrations?

Nobody likes to spend hours going through terrible API documentation.

And no marketing team wants to wait for some nocturnal back-end wizard to finally crack the code that connects one tool with another.

A Zapier connection gets the ship moving — at least until the back-end gods responded to the nocturnal creature’s pleas.

Does the tool have a supportive community around it?

There’s nothing worse than having to search every inch of the internet not to be able to find the answer you’re looking for.

Does the tool allow for custom experiences or is it cookie-cutter?

Some tools may look pretty, but they are cookie-cutter.

Shopify is an example that comes to mind.

Do you really with your online store to look like everyone else’s? If not you better have a brilliant team of developers at hand to update the living heck out of every experience.

Your tech stack should allow you to stand out from the noise.

Does the tool use growing or aging technology?

Open Google Trends.

Type in the tool/technology’s name.

  • If interest is growing, that’s a good sign.
  • If interest is fading, you probably should look at why it’s losing market share.

I find that there’s usually a new competitor making life a little easier.

You don’t want to look back in 5 years sitting with ancient tech without updated support.

If I can leave you with one final piece of advice, make sure every tool you use allows you to seamlessly migrate when you decide to move on in the future.

I’m curious, what’s in your tech stack for:

  • Project management
  • Marketing/CRM
  • Backend/CMS
  • Frontend

Adblock test (Why?)

I Completed a Year of Quitting My 9–5. Here’s What I’ve Learnt So Far.

I quit my 9–5 at 25 to be a full-time writer.

Image by the author

A year ago, my tummy was churning with anxiety about quitting my safe job.

My office was a 6-minute drive from home and my company was financially strong and the epitome of what a ‘secure job’ means. No layoffs during the pandemic as well, which was a sticky factor.

And here I was, a young 25-years-young with under 3 years of work experience, wanting to be a writer.

Sounds stupid, right?

Here’s what I’ve learnt so far about this path and life.

The beginning of everything starts from inside

If your mind isn’t hard-wired to a growth mindset, forget success of any kind. Being self-employed is about:

  • uncertainty
  • failing often
  • showing up through it all

It takes an abundance mindset to do this. It takes grit to show up and be creative even when you don’t feel like it.

Don’t depend on others to pay your bills

Including your company. We’ve been seeing layoffs for the last two years, haven't we?

After my first client who I was depending on ghosted me, I realised I will never depend on one client for impacting my monthly finances. I didn’t even want to depend on one source, which is why I started a course and made digital products.

Start diversifying as early as possible.

Weed out sub-average pals

You don’t need most people in your life. When you become mindful of how finite time is, you might as well spend it with people you love and who genuinely mean a lot to you.

Weeding out surface-level friends makes you more energetic.

Be open to the idea of possibilities

Blame it for being naïve or overly optimistic, but I’ve always believed that good things are coming my way and I will receive nothing but excellence.

Even when things go downhill, this thought keeps me going.

In Hindi, we have a saying,

“‘उम्मीद पर दुनिया कायम है”

This translates to — the world lives on hope.

Always be hopeful because a negative mind attracts nothing good anyway. So why not.

Do the work, forget the results

I stopped getting affected by the results early in my journey after I read Seth Godin’s The Practice: Shipping Creative Work.

The results aren’t in my control. The process is. Why waste precious time whining?

People pay only for these 3 things

  1. What you solve for
  2. How you make them feel
  3. What returns do you put on the table

As long as you direct your products or services towards this, you will make money.

I’m not a salesperson and don’t know the theories and concepts of Sales, but this works.

Talking about money…

There’s enough money to be made

When I was earning X last year, I knew that earning 2X will take me at least 5 years. The amount seemed big and unattainable.

Now, with time, money isn’t the motivator because it's an unsustainable motivation. It’s not the reason you show up every day, and it eventually finds its way to you when you give out value.

Now, it all feels attainable.

The only limitation is your mind because the world has enough money.

How much you make is on you

As a writer, I could either:

  1. Take lots of clients. Maybe open an agency later and even get passive income by outsourcing gigs to others.
  2. Take one or two good clients.

The second one comes is what I’ve aimed for since day one. It’s also more stress-free because a high-paying client doesn’t negotiate or make your life hell. They respect creativity.

If you’re a freelancer, you have this choice.

Information diet is crucial

I still don’t get how people spend an hour watching people dancing on videos. It’s like feeding your brain absolute crap and expecting rainbows from life.

What you take in is what you’ll put out in the world.

Protect your energy and be conscious of your consumption, especially online.

Family first

I’ve noticed a pattern.

When I’m stressed out or getting close to burnout, I spend less time with my family, even when I’m not working. When I’m in balance, I’m spending more time and laugh a lot more.

Striking a balance is something I am still working on, so I can put my family first.

I don’t want to be a CEO

I’m lazy, and I truly don’t desire a stressed-out life.

When I solo-travelled to Europe at 21, I realised how we’re such a tiny speck in this world and how beautiful it feels to just live. I realised that material isn’t the source of happiness and titles and tags are just a construct by society.

Only who you are defines you, and nothing else.

It’s then that I decided I’ll prioritise living and experiences — this is being rich, according to me.

I want to take out more time to do things I enjoy instead of making a graph go up all my life.

I don’t want to be a CEO of a big company. I don’t even desire to open an organisation that makes millions.

A simple and driven life is what I strive for.

Reading The Minimalist Entrepreneur by Sahil Lavingia validated what I was feeling.

This makes you richer than money

In a few weeks, I’m taking a 4-week long holiday. I wouldn't have imagined doing this or afford it with my full-time job.

I won’t carry my laptop and will be away from work without an ounce of worry about my career.

Owning your time is a powerful feeling.

‘Enough’ is a state of mind

I slip out of gratitude sometimes even though I’ve been writing a gratitude journal (10 things I’m grateful for) every day since 2017.

Now, I’m moving towards making peace that enough is a state of mind and no amount of anything can be enough if you look at it that way.

Mindset matters, always.

The only fuel to the fire

Purpose comes to you when you look within.

Purpose is fuelled when it helps improve lives.

Find the two and you’ll be an unstoppable force.

Most people will never find their purpose because in this hyperstimulated world, they aren’t taking out time to look within.

Don’t be like most people.

Consider everything as an experiment

That way, either it works out, or it doesn’t. It’s not a big deal.

It was such random experiences that enabled me to side hustle, quit, and start a business.

The power of trying new things for fun is underrated. You never know where they’ll lead you!

It’s a good life

I feel good every single day. Sunday evenings aren’t filled with anxiety. I’m pumped to create, and I’m happy doing what I do.

It’s a good life.

The one I’m grateful for multiple times each day.

Adblock test (Why?)

I Completed a Year of Quitting My 9–5. Here’s What I’ve Learnt So Far.

I quit my 9–5 at 25 to be a full-time writer.

Image by the author

A year ago, my tummy was churning with anxiety about quitting my safe job.

My office was a 6-minute drive from home and my company was financially strong and the epitome of what a ‘secure job’ means. No layoffs during the pandemic as well, which was a sticky factor.

And here I was, a young 25-years-young with under 3 years of work experience, wanting to be a writer.

Sounds stupid, right?

Here’s what I’ve learnt so far about this path and life.

The beginning of everything starts from inside

If your mind isn’t hard-wired to a growth mindset, forget success of any kind. Being self-employed is about:

  • uncertainty
  • failing often
  • showing up through it all

It takes an abundance mindset to do this. It takes grit to show up and be creative even when you don’t feel like it.

Don’t depend on others to pay your bills

Including your company. We’ve been seeing layoffs for the last two years, haven't we?

After my first client who I was depending on ghosted me, I realised I will never depend on one client for impacting my monthly finances. I didn’t even want to depend on one source, which is why I started a course and made digital products.

Start diversifying as early as possible.

Weed out sub-average pals

You don’t need most people in your life. When you become mindful of how finite time is, you might as well spend it with people you love and who genuinely mean a lot to you.

Weeding out surface-level friends makes you more energetic.

Be open to the idea of possibilities

Blame it for being naïve or overly optimistic, but I’ve always believed that good things are coming my way and I will receive nothing but excellence.

Even when things go downhill, this thought keeps me going.

In Hindi, we have a saying,

“‘उम्मीद पर दुनिया कायम है”

This translates to — the world lives on hope.

Always be hopeful because a negative mind attracts nothing good anyway. So why not.

Do the work, forget the results

I stopped getting affected by the results early in my journey after I read Seth Godin’s The Practice: Shipping Creative Work.

The results aren’t in my control. The process is. Why waste precious time whining?

People pay only for these 3 things

  1. What you solve for
  2. How you make them feel
  3. What returns do you put on the table

As long as you direct your products or services towards this, you will make money.

I’m not a salesperson and don’t know the theories and concepts of Sales, but this works.

Talking about money…

There’s enough money to be made

When I was earning X last year, I knew that earning 2X will take me at least 5 years. The amount seemed big and unattainable.

Now, with time, money isn’t the motivator because it's an unsustainable motivation. It’s not the reason you show up every day, and it eventually finds its way to you when you give out value.

Now, it all feels attainable.

The only limitation is your mind because the world has enough money.

How much you make is on you

As a writer, I could either:

  1. Take lots of clients. Maybe open an agency later and even get passive income by outsourcing gigs to others.
  2. Take one or two good clients.

The second one comes is what I’ve aimed for since day one. It’s also more stress-free because a high-paying client doesn’t negotiate or make your life hell. They respect creativity.

If you’re a freelancer, you have this choice.

Information diet is crucial

I still don’t get how people spend an hour watching people dancing on videos. It’s like feeding your brain absolute crap and expecting rainbows from life.

What you take in is what you’ll put out in the world.

Protect your energy and be conscious of your consumption, especially online.

Family first

I’ve noticed a pattern.

When I’m stressed out or getting close to burnout, I spend less time with my family, even when I’m not working. When I’m in balance, I’m spending more time and laugh a lot more.

Striking a balance is something I am still working on, so I can put my family first.

I don’t want to be a CEO

I’m lazy, and I truly don’t desire a stressed-out life.

When I solo-travelled to Europe at 21, I realised how we’re such a tiny speck in this world and how beautiful it feels to just live. I realised that material isn’t the source of happiness and titles and tags are just a construct by society.

Only who you are defines you, and nothing else.

It’s then that I decided I’ll prioritise living and experiences — this is being rich, according to me.

I want to take out more time to do things I enjoy instead of making a graph go up all my life.

I don’t want to be a CEO of a big company. I don’t even desire to open an organisation that makes millions.

A simple and driven life is what I strive for.

Reading The Minimalist Entrepreneur by Sahil Lavingia validated what I was feeling.

This makes you richer than money

In a few weeks, I’m taking a 4-week long holiday. I wouldn't have imagined doing this or afford it with my full-time job.

I won’t carry my laptop and will be away from work without an ounce of worry about my career.

Owning your time is a powerful feeling.

‘Enough’ is a state of mind

I slip out of gratitude sometimes even though I’ve been writing a gratitude journal (10 things I’m grateful for) every day since 2017.

Now, I’m moving towards making peace that enough is a state of mind and no amount of anything can be enough if you look at it that way.

Mindset matters, always.

The only fuel to the fire

Purpose comes to you when you look within.

Purpose is fuelled when it helps improve lives.

Find the two and you’ll be an unstoppable force.

Most people will never find their purpose because in this hyperstimulated world, they aren’t taking out time to look within.

Don’t be like most people.

Consider everything as an experiment

That way, either it works out, or it doesn’t. It’s not a big deal.

It was such random experiences that enabled me to side hustle, quit, and start a business.

The power of trying new things for fun is underrated. You never know where they’ll lead you!

It’s a good life

I feel good every single day. Sunday evenings aren’t filled with anxiety. I’m pumped to create, and I’m happy doing what I do.

It’s a good life.

The one I’m grateful for multiple times each day.

Adblock test (Why?)

نجات‌دهنده از آسمان آمد

و به مشتی کشاورز بیچاره طرز کار با آرپی‌چی، مسلسل اتوماتیک، خمپاره‌انداز و راکت دوش‌پرتاب را آموخت ...


۱۳۵۷ برژینسکی در پاکستان در اردوگاهی در مجاورت مرزهای افغانستان 



بیست‌سال بعد در ژانویه ۱۹۹۸ [۱۳۷۷] مجله فرانسوی Nouvel Observateur مصاحبه‌ی قابل تأملی را با برژینسکی مشاور امینتی رئیس‌جمهور آمریکا جیمی کارتر منتشر کرد. او در این مصاحبه علنا اعتراف می‌کند که آمریکایی‌ها حمایت از “مجاهدین افغان” را ۶ماه قبل از هجوم نیروهای شوروی به افغانستان آغاز کرده‌اند. او در جواب این پرسش که آیا از این اقدام پشیمان است می‌گوید: «از چه چیزی باید پشیمان باشم؟ این عملیات مخفی یک ایده‌ی درخشان بود. ما از این طریق روس‌ها را به تله‌ی افغانستان انداختیم. باید از این کار پشیمان باشم؟ همان روزی که روس‌ها از مرز افغانستان عبور کردند برای جیمی کارتر در پیامی نوشتم: حالا ما این فرصت را داریم که اتحاد جماهیر شوروی را وارد یک “ویتنام” کنیم». و واقعا هم مسکو مجبور شد ده سال متمادی به جنگی تن دردهد که از توجیه آن ناتوان بود. این چالش بنیاد اخلاقی اتحاد جماهیر شوری را سست کرد و متعاقبا به ویرانی شوروی انجامید.

مصاحبه‌کننده می‌پرسد، شکل‌گیری بنیادگرایی اسلامی را چه می‌گویید؟ پرورش تروریست‌های آینده و مسلح‌ساختن آن‌ها خطا نبود؟ برژنسکی پاسخ می‌دهد: اصلا و ابدا! «برای تاریخ جهان چه چیزی با اهمیت‌تر است، طالبان یا فروپاشی اتحاد جماهیر شوروی؟ وجود عده‌ای مسلمان خشمگین یا آزادسازی اروپای مرکزی و پایان دادن به جنگ سرد؟».

 

نجات‌دهنده از آسمان آمد

و به مشتی کشاورز بیچاره طرز کار با آرپی‌چی، مسلسل اتوماتیک، خمپاره‌انداز و راکت دوش‌پرتاب را آموخت ...


۱۳۵۷ برژینسکی در پاکستان در اردوگاهی در مجاورت مرزهای افغانستان 



بیست‌سال بعد در ژانویه ۱۹۹۸ [۱۳۷۷] مجله فرانسوی Nouvel Observateur مصاحبه‌ی قابل تأملی را با برژینسکی مشاور امینتی رئیس‌جمهور آمریکا جیمی کارتر منتشر کرد. او در این مصاحبه علنا اعتراف می‌کند که آمریکایی‌ها حمایت از “مجاهدین افغان” را ۶ماه قبل از هجوم نیروهای شوروی به افغانستان آغاز کرده‌اند. او در جواب این پرسش که آیا از این اقدام پشیمان است می‌گوید: «از چه چیزی باید پشیمان باشم؟ این عملیات مخفی یک ایده‌ی درخشان بود. ما از این طریق روس‌ها را به تله‌ی افغانستان انداختیم. باید از این کار پشیمان باشم؟ همان روزی که روس‌ها از مرز افغانستان عبور کردند برای جیمی کارتر در پیامی نوشتم: حالا ما این فرصت را داریم که اتحاد جماهیر شوروی را وارد یک “ویتنام” کنیم». و واقعا هم مسکو مجبور شد ده سال متمادی به جنگی تن دردهد که از توجیه آن ناتوان بود. این چالش بنیاد اخلاقی اتحاد جماهیر شوری را سست کرد و متعاقبا به ویرانی شوروی انجامید.

مصاحبه‌کننده می‌پرسد، شکل‌گیری بنیادگرایی اسلامی را چه می‌گویید؟ پرورش تروریست‌های آینده و مسلح‌ساختن آن‌ها خطا نبود؟ برژنسکی پاسخ می‌دهد: اصلا و ابدا! «برای تاریخ جهان چه چیزی با اهمیت‌تر است، طالبان یا فروپاشی اتحاد جماهیر شوروی؟ وجود عده‌ای مسلمان خشمگین یا آزادسازی اروپای مرکزی و پایان دادن به جنگ سرد؟».