For Software Engineers, Engineering, Programming Tomer Ben David en-us Wed, 21 Feb 2018 12:43:46 +0000 Wed, 21 Feb 2018 12:43:46 +0000 Yes For Software Engineers, For Software Development, Programming This is software engineering podcast where we discuss scalability, engineering, functional programming, api design, UI, machine learning. This is software engineering podcast where we discuss scalability, engineering, functional programming, api design, UI, machine learning. Tomer Ben David Jekyll v3.6.2 Episode 5: System Design and Scalability (Podcast) Yes Tomer Ben David 664.0 Fri, 13 Oct 2017 12:00:00 +0000

Basic understanding of system design is required for creating a better and scalable architecture. We have to understand what are web servers, app servers, DNS, caching techniques, network, programming models, the different kind of databases, and most importantly how you compose all these components together to create a scalable architecture.

]]> Education
Episode 4: Scalability Definition and Analogies (Podcast) Yes Tomer Ben David 688.0 Sun, 08 Oct 2017 12:00:00 +0000 Scalability - Definition and Analogies (Podcast)

Is it possible to define scalability? if so what is it’s proper definition. Can we devise proper analogies to software development scalability and real world old fashion scalability? In this episode we are going to touch upon these two topics. I hope you enjoy the show!

]]> Education
Episode 3: Technologies VS Architectures Episode (Podcast) Yes Tomer Ben David 703.0 Sat, 07 Oct 2017 12:00:00 +0000 Technologies VS Architectures

Too many times people are mistakenly replacing architectures with technologies. Today’s hyped technology becomes an “architecture”. How should we differentiate between technologies and architectures? can we do that at all? what are the similarities and differences?

]]> Education
Episode 2: Scalability And Startsups (Podcast) Yes Tomer Ben David 687.0 Fri, 29 Sep 2017 12:00:00 +0000

This is For Software Engineers Podcast Episode 002

Scalability Part 2 is it possible to bake in scalability into a startup. Should we do that at all? How fast can we move on with our software development. The answer is a basic design issue which we should take into account and discuss.

so this is a scalability part two and today I want to continue to discuss the topic of a scalability and doing this by asking the right questions so the first question we are going to ask is the whether it is possible to bake in scalability a into a startup now even a better question would be that if you are already a startup whether you want to bake scalability in because if you will do that then obviously this would have implications on how fast you can move on with your software development so the answer to that I think at least in my mind is very simple and it is that first you should be aware of what scalability means and this is what we are going to discuss in this episode and once you’re aware of it then you should not block I mean you should design your software you don’t have to implement scalability from zero from 4f4 a little fast going if you don’t have really too many customers I mean if you have two customer 10 customers 100 you still even many more right you still don’t need the scalability in your tool set however what you need to know is that what is better doing is that is that you you what you baking is not the solution is that when it comes the time that you need to change your architecture that you do you want need to recreate everything from scratch so there is this other possible they may be that you know that when the times the time will come you will be able to recreate everything so in this case this is okay but you don’t really know that and if you don’t know that then the thing is that with very little effort you can avoid doing this revolution and this recreation or rewrite of the whole codebase and how can you do it you can do it with simple steps for for example if you have a data base you can always abuse the database or or utilize it to the end you can use every little non standard SQL if it’s a relational database every little non-standard query into this database and just use it all over the codebase and then when times come you have and you need to you understand you want to change the database man because it costs too much money we want to move to an open source solution then you find out that you need to rewrite many of your qualities and maybe it impacts all of you all of your software but if you want your software in a way that when you access the database you don’t you less care which database you access you less care whether it’s an even NoSQL or relational database you just do get into the database get by key and set by King and maybe you do some searches and when you have some specific queries then you move them to the side to specific files when later you can take those specific files even you you can call it by simple by specific names also so that later on when you move on to a different kind of database or when you change your architecture and you cannot do these complex searches on your database I mean you need to change somehow the way you do searches maybe you now have shouting we’ll talk about this concept in the future so so that in the future it will be much easier to access data but the database so if you are using MySQL then then first I will recommend you for example right to use another layer of abstraction now when we say another layer of abstraction you might think oh this is going to take me too much time to create this layer but but no it just means another class or or whatever that whenever you call the database you first call it and it chooses the implementation and instantiate it for you oh if you have a different way now we are also not found of over-engineering so you should be a very careful not to over engineer your solution so we are talking about very simple things I didn’t really mention a map that loads the type of the database form a configuration and this configuration is injected and stuff like this all I said is that when you call your first database you go to another function which is general one and it calls your database this is the right amount of engineering and if you feel you need if you really feel you need more engineering then you can move it to a configuration file but right now when you’re early on all you on your startup then you have a single database so don’t over engineer it so so there is this this balance that you always need to take care of of of an engineering that will cause you also to slow down and under engineering that will cause you very bad implications even the future if you get too much specific in your in your solution and this question is also a very major one when we discuss the whole topic of scalability how much engineering should you put into your solution or how maybe how much over engineering should you put into your solution so that in future when you need to do this these very factors when you need to do these changes when you need to go high then it will form one hand be easy and from the other hand be easy for your current software developers to develop your code and be happy with it and not mess all day with over-engineered code so the answer to that is is a little bit of art I mean there is not no specific solution but but the main guideline is first that you need to engineer your code first so that it will be clear and clean and those are other aspects but they are related because many times a non-count means over-engineered code so it should be first clean and and by clean we don’t mean too many obstructions it means it means in general that that you should always try to read your code and understand from the user perspective whether it is clean and clear for the riddle of the code and you should apply different use cases such as ask yourself ok what if I need to change the database ok I will I need to refactor the whole thing and again if you understand that you need to refactor the whole thing this is this is not really a good point but if you understand that you have a set of queries or a set of procedures that reside on the side on some specific place that only them you need to take and change then this is a good point now if you rely on the architecture of your database let’s say for a replication of some kind of shouting then it’s ok it’s a great however the recommendation is to utilize a minimal set of features which you can form your database which will satisfy you I mean it’s okay to use feature formed a various databases migration from one kind of database to another will never be easy however sometimes you need to note that databases try to push you and when those try to push you into utilizing features which you can you which you don’t necessarily need and which you can with very little overhead have a simple implementation so over designing in this way and over using and abusing the features of database can sometimes harm you this is very delicate and it’s not correct for all cases but in most cases I can see that you can utilize the database in your favor and the database both to you and it not you and your architecture is boring to the database you should utilize it and not be abused by it and with that we ended this episode and I hope you enjoyed it and see you next time thank you for listening you

]]> Education
Episode 1: Scalability Introduction (Podcast) Yes Tomer Ben David 696.0 Thu, 14 Sep 2017 12:00:00 +0000 This is For Software Engineers Podcast Episode 001


Scalability is not only an interesting topic but, it is also a topic where it’s really difficult to find well-organized resources for its proper study. It’s very difficult if not impossible to find the necessary scalability resources teaching you from zero and getting you to be a software engineering expert on the subject. You need to gather your resources. This is why we are very much interested in pushing through and trying to evaluate what scalability is and how to achieve it by finalizing and organizing the topic.

Scalability - it’s not only about architecture/servers

The first question to ask about scalability is whether it is a business problem or a technological problem. Well, you can think originally about scalability as mere high-tech problem where you need to scale your databases or services. However, you need to remember that the scalability problem has been existing throughout the human history. We needed to know how to scale our food growth. We need to know how to scale our car manufacturing. You see, scalability happened before silicon valley got filled with programmers.

At your high-tech business, you can view the scale-it challenge as a reflection of real physical processes scaling, these physical processes also need to scale. When we discuss scalability it is not merely a technological aspect it is not just a set of diagram or blocks you draw on the whiteboard or just scaling requests into multiple servers.

It’s a real-life situation and a problem which you solve in surprisingly similar ways in both low-tech and high-tech industries. When you have an organization you have people. Some of these people are responsible for creating your architecture, maybe the architects or the senior developers, or, if you are a small company then all developers are doing architecture! ofcourse it’s best that also in a big company all developers are in a position to create their architectures but still there is someone or a few architects on the top. So - scalability is first and foremost a people and business ‘thing’ to deal with! The people are creating the architectures so we need to scale our business by enabling our people to create scalable architectures, we first need to enable the people!

Humans Create Architecture

When we are talking about scalability we should see in front of our eyes people who are creating technology. An organizational structure as far fetched as it can be seen in developers eyes is actually rather important in that manner. The structure questions such as what should be the team size? When considered and answered well - would cause you to be able to create better an architectures. Now, when you choose your way organization structure you need to take into account a few considerations and some of them are how much communication do you need between with people. You want the least amount of communication which will allow people to do a great job.

Obviously, if people need to communicate too much one with another, then not only your business will not grow fast, and will not be scalable but also the architectures they create will be less optimally aligned with the solution you want.

Breaking The Rules

Another question to ask is whether you should have rules. A tight rule system in your possession have implications. You can choose to have very tight rules and processes but it can also hinder your ability to scale. That is because, if you impose too many rules on the people they have some less space to take off, and, when you scale you need to break some rules. Now, you can say that you apply a rule that enables people to break the rules. But usually this is a snitch, and you need to be able to break your rules in a more natural way. In order to scale you need to be able to have creative thinking and creative thinking requires breaking the rules.

CEO’s - software engineers or not?

Let’s take like the five top IT companies like Amazon, Google, Facebook, Twitter, Microsoft. You see that the CEOs are coming from a technological background, which makes you think that a person with the technological background can create in today’s atmosphere a more scalable solution or ideas, now, it is indeed very important for anyone to be aware of the architectural decisions your people make, it’s super important but it’s not a top must, airbnb founders are not technical. We will just say here that it’s a very high recommendation, it’s best of course if the CEO is coming from technological background, but marketing, finance, and more aspects are also super important, we are developers, we tend to disregard these aspects but hell they are important and CEO should be very well familiarized with them. The claim is this, it’s easier for a software engineer to learn finance than the other way around. The CEO should at least understand the core concepts, as an engineer you tend to disparage about them, marketing, finance, are very very important to be only a few of the possessions of the CEO.

The beginning of scaling

When you take any solution or any product you create, the basic question to ask is, how do you scale it when you have multiple ways of doing that process. First, you can duplicate, I mean, if you have one person servicing the requests coming for the customers, then, you can simply like duplicate, or hire more people.

The same goes with the servers, if, you have like mainly a stateless server, then, the basic way in which you scale your solution is to simply create duplicates of this server. Now this is the simplest solution and it has its drawbacks, but, it has many advantages. The main advantage is that it is very very simple to implement, but, it is also a limited one - because you cannot always do that, you need to design your services first to support that. So the first rule that we had is that if you have a solution or a service or a server that you create uf it is mainly stateless then you can simply duplicate it. The same goes with a database which is yet another service, or a file system - yet another service. Whatever you have simply duplicate if the service was built for it! This would allow for servicing more requests - easily.

When you have state. Now usually what people are doing is that if you need to store some state then if you have a database which is specific for state storage, then you prefer storing the state there, and not in the app layer, because if you store it in the application server then you have the problem of which server to access in order to get or store this state. Because if we have let’s say a user named John and we want to update its name - so if we access one server and update its name and in parallel let’s say that we have another process which updates its address and it accesses a server, then, the problem might be that one update one my state is conjuring with another update.

You might simply overwrite the other change so what many solutions do is that they require you to contact one server to do all the writes, all writes are going through one server, a so-called “master”. A single server and then via replication delegates and replicates. And you read fro the slaves. If you don’t want to do that then depending on your specific scenario you might need to apply some solutions which can do it in a more distributed way - they are called an agreement protocol like raft or Paxos, but they are more aligned with configurations than real time data, there is an agreement overhead for using them.

In this way, you can like contact more than one server for an update, as we are able to contact one of a few servers to get the response we have scaled our system. With agreement protocols the servers need to agree on the result, they do some processing for that purpose and communication. Because before they agree, they ask themselves if they are actually updated with last value, but, what is important to understand from this simple first rule is that we simply duplicate our service this is rather a trivial right - assuming you designed for it.

Your Money or Horizontal Scaling!The basic scalability technical issue is all about having your services serve more unit of works with more resources. For that in today’s world we utilize in most cases horizontal scaling, we prefer that over vertical scaling, while we would elaborate on that in future posts, let’s present the basic plot for you to know about vertical vs horizontal scaling cost!

The below diagram shows the difference in cost for vertical scalability vs horizontal one.

Web Scalability For Startup EngineersThe Image Is Taken From: Web Scalability For Startup Engineers

The author shows that scaling horizontally for example with CDN is not only cost-effective but often pretty much transparent! “The more traffic you generate, the more you are charged by the provider, but the cost per capacity unit remains constant”.

Choose simple solutions

We simply duplicate our service so we can service more a request and you can do this as we said in any component - we simply duplicate the instances of the database - you duplicate the instances of the services. Now, this is very naive but it’s good actually it’s good that it’s naive because it forces you to choose simple solutions. As long as you manage to be smart and choose simple solutions which answer properly your problem, then you can apply this all scaling issues. Now we will see in further posts that when you cannot apply such a simple rule or when your scale is too high then you cannot simply use this method. You will need to apply more methods into your scalability and solution so the first rule is simply to duplicate it’s very dumb. And if you cannot do that, you will need to apply other scaling methods such as sharding etc but let’s leave that to the next posts.

We have only scratched the surface

Hey, we have only scratched the surface here, but this got long enough, i’ll get back to the more interesting topics and internals in future posts. The bottom line of this post is, scaling is not only a technical problem, scaling is much about if you can find a simple duplication pattern, scaling is about splitting by functionality, scaling is about sharding data and services, and last and not least try to do it with commodity hardware in a horizontal scale way!

]]> Education