Posted on

Microsoft Azure Cloud Concepts

Introduction to Cloud Computing

Let’s start by doing an introduction to cloud computing. Let’s take a trip in time. If we look maybe 10, 15 years back, before even virtualization, in each company’s datacenter we had a ton of servers, and each server had a different purpose, maybe running on different hardware, and even with different operating systems. Each new application that you installed, the vendor required that their application ran on a dedicated server. Each one of those servers had their own CPU, RAM, and hard drive resources, and of course, each one of them needed enough resources for utilization at peak time. But what this did is that, on average, most servers were really underutilized and organizations were spending a ton of money on hardware that most of the time was not even used at 10% of its capability.

But then we started to implement virtualization, which allowed us to run multiple virtual machines on a single virtual host, so we were really able to get more usage out of our hardware and cut down on space, cooling, and of course, costs. However, even with virtualization, we still had a few disadvantages, such as high upfront costs since we need to buy powerful virtual hosts, which we would then need to keep for five years for the amortization of cost. We still need to pay for space in the data centre, as well as electricity and utility costs for cooling and other server needs. Furthermore, hardware maintenance is still needed as this can break down, network cards can go bad, and so on. Virtualization is still way more cost-efficient than dedicated hardware. Don’t get me wrong, but there is still space for improvement, and this is where cloud computing comes in.

Cloud computing enables companies to consume a compute resource, such as a virtual machine, storage or an application as a utility, just like electricity, rather than having to build and maintain computing infrastructure in‑house. In a cloud environment, you have the cloud provider, which owns their datacenter and manages all of the hardware, like servers, networking, and, of course, virtualization. As the cloud is fully built on the principle of virtualization, no client ever has direct access to the hardware, simply to a virtualized environment. All of those resources are pulled together and then shared to multiple clients that all consume that shared hardware. Those clients don’t need to know what servers they run on or on how many servers their different environments are running, they simply consume a service and the cloud provider is the one making sure there are enough shared resources to handle everything.

In a cloud environment, users simply select what services they want to use with each service having a different price per user or per minute of utilization for that specific resource. In a cloud infrastructure, this should be self‑service by the user, and the provisioning should be fully automated by the cloud provider and delivered in an almost instant fashion. Now let’s talk a bit about cost. In a cloud model, services are billed on demand by the minute or by the hour, depending on what service you are using. This on‑demand billing allows organizations to create resources when needed and then stop paying for them when they don’t need them anymore. This way, organizations can be more dynamic and cost-effective, as well as reduce the upfront cost. Since the money you pay for the cloud does not get depreciated over multiple years, it’s a resource that you use right away, the cloud cost usually goes into the operating expenses, or OpEx, instead of the capital expenses, or CapEx.

Here is an example of billing for a virtual machine in Microsoft Azure. First of all, I need to select the specifications of the machine that I want. In this case, I’m selecting a virtual machine with 2 cores and 7 GB of RAM. You can see right away the cost would be about $0.36 an hour, and I can also select the operating system, in this case, Windows. Because Microsoft owns Windows, the cost that I paid for this virtual machine also includes the licensing for the Windows operating system it will be using, so now I’m getting that license as a service as well. For the estimate, I can also choose how many hours I expect this virtual machine to be used per month, so if I use this virtual machine for 730 hours, my cost would be 262.85 per month. And as you can see inside Azure, virtual machines are built per second, so it’s really flexible, you only pay for what you use. Most cloud providers will also offer you savings if you pre‑pay for a number of years. So, if I know that I will need this VM for three years to run 24/7, I could save up to 55% of my computing cost, which could make sense for some servers that are always up. Cloud services can also be scaled depending on demand and even automatically.

In this case, I have an app service plan in Azure, which is a platform in which you can host websites, and I can enable auto scale on it. This way, I can say that, for example, when the CPU usage goes above 70%, add more CPUs or instances to that service. This can be really useful for public websites or different apps, though you pay a set amount at rest or when they’re not used a lot, but if you have a peak or lots of people connecting and using that service at the same time, increase those resources, pay a bit more for that specific set of time, and then go back to normal. And this is why we say that the cloud offers rapid elasticity. Whenever you need it, you can grow the amount of resources that you use and pay for, and then right away when that load is not there anymore, you can always go back to minimum spending and really only pay when you need those resources. Something else that is a big advantage of the cloud as well is the reliability.

Cloud provider takes care of high availability and disaster recovery

In a cloud scenario, the cloud provider takes care of high availability and disaster recovery on their platform. Just to go over the terms so you can see the difference between those two, high availability is usually to protect us against software and hardware failures. Those are usually very local, like a rack goes down, a server loses power, a service crashes on one of the servers, and things like that. On the other side, disaster recovery is something much bigger, like a natural or human‑induced disaster. Take, for example, a flood, fire or an earthquake that puts the whole datacenter down. With cloud computing, you can also benefit from fault tolerance, which is very similar to high availability, but offers zero downtime. So when you look at the service level agreements for your cloud provider, make sure you take a look at their reliability service level agreement for high availability, disaster recovery, and fault tolerance. Now, as you can imagine, if you want to have fault tolerance and disaster recovery in your own datacenter, the cost can go really fast, as you would need a second datacenter on the other side of the country for which you need to pay servers, networking, utilities, and so on. So from a cost perspective, the cloud can offer a much better solution for a better cost since the cloud provider already has those, so you would benefit from the economies of scale. If we look at Azure a bit more specifically, there are Azure datacenters in over 60 regions worldwide, allowing you to implement fault tolerance across not only multiple states, but continents.

Understanding Types of Cloud Computing Services

Types of Cloud Computing Services

Let’s start by introducing the types of cloud computing services. There are multiple types of cloud computing services, but the three main ones are Infrastructure as a Service, Platform as a Service, and Software as a Service. Let’s take a look at what the differences are. What really differs between those cloud computing services is how much you manage versus how much the cloud vendor manages.

Let’s start with on‑premises where it’s really easy, you’re the one that manages everything from storage to the datacenter to networking, virtualization, and applications on top of it.

Infrastructure as a Service (IaaS) delivers cloud computing infrastructure to organizations, including things such as servers, networks, and storage. You, as the client, still manage the operating system, the applications, as well as the data.

Platform as a Service (PaaS) is mainly used for applications and provides a framework for developers that they can build upon and use to create customized applications. All servers, storage, and networking are managed by the third‑party provider while the developers can maintain management of the applications.

Our last option is Software as a Service (SaaS) in which you simply enjoy the service, pay a fee, but you don’t manage anything at all. Everything is managed by the vendor. A majority of Software as a Service application is run directly through the web browser and do not require any downloads or installation on the client-side. While this may seem a bit complicated to grasp at first, let’s take a look at the same model, but from a different perspective.

Let’s compare our cloud computing services to everyone’s favourite food, pizza. Our on‑premises model would be similar to making pizza at home from scratch. You make your own dough, you cut your own toppings, you put it in your own oven, and you eat it at your own table. Our Infrastructure as a Service model is similar to getting frozen pizza from the supermarket and cooking it at home. You pay for the part of the service, the pizza dough, tomato sauce, toppings, cheese, but you still cook it yourself and eat it at your own table. The Platform as a Service is similar to pizza delivery where the pizza comes to you already made and hot, you simply need to pour the drinks and eat it at your own table. And finally, the Software as a Service is like dining out. You don’t have to bring or make anything except your wallet, but everything is taken care of by the vendor, you simply pay the bill for what you consume. Hopefully, this comparison with pizza allows you to better view the differences between the cloud computing service models.

Let’s take a look at some examples of cloud vendors and services in each category. For Infrastructure as a Service, some of the big players are Microsoft Azure, Amazon Web Services, or AWS, and Google Compute Engine. In the Platform as a Service, some big players our Heroku, Amazon Elastic Beanstalk, as well as Azure Logic Apps. In the Software as a Service, we’re looking at Office 365 by Microsoft, Google G Suite, Salesforce, and Dropbox. And, of course, those are just a few of the most popular ones, but there are hundreds, if not thousands of examples of cloud providers with the Software as a Service one probably the most popular one.

If we dive deeper and focus only on Microsoft, an Infrastructure as a Service, we have Azure Compute, which is the name for the virtual machines, and Azure Storage. In Platform as a Service, we have things such as Azure Logic Apps, Azure Functions, Azure Web Jobs, and Azure Automation. And in the Software as a Service, we have services such as SharePoint Online, OneDrive for Business, Microsoft Teams, and the Power Platform. Those are just a few examples. Microsoft has over a dozen services in each one of those categories.

Cloud Computing Services Scenarios

Now that we have seen the basics, let’s take a look at some scenarios for each cloud computing type.

Let’s start with Infrastructure as a Service. Infrastructure as a Service is, first of all, perfect for test and development scenarios as it allows you to turn on and off dev machines only when needed, and you don’t need to pay for the hardware full time. Storage and backups are also a great scenario for Infrastructure as a Service as the pricing to keep backups in the cold storage are very advantageous. Storage and backups are also a great scenario for Infrastructure as a Service as the price to keep backups in cold storage are usually very good. Next up, high-performance computing and big data analysis, which are often things you only need for small periods of time, but require very powerful computers, can be a great way to use Infrastructure as a Service as you only pay for the time you need.

Now let’s talk about Platform as a Service. A great scenario is an analytics or business intelligence. Tools provided as a service with Platform as a Service allow organizations to analyze and mine their data, finding insights and patterns and predicting outcomes to improve forecasting, product design decisions, investment returns, and other business decisions. Platform as a Service is also great for developers. Platform as a Service lets developers create applications using built‑in software components, and cloud features such as scalability, high availability are included, reducing the amount of coding that developers must do.

Finally, for Software as a Service, the main scenarios are getting access to sophisticated applications without the need to manage any of the infrastructures yourself. From a Microsoft perspective, imagine all of the work needed to install SharePoint, Exchange, and Skype for Business servers on‑premises versus just using the same tool in the cloud in a matter of minutes. Software as a Service also is basically instant where if you want to add more users, you just enable their license and they can use the service.

Understanding Cloud Computing Deployment Models

Let’s start by looking at the different types of cloud computing deployment models. There are multiple types of cloud deployment models out there.

Public Cloud

First one we’ll talk about, which is the most popular, is the public cloud. In the public cloud, you have a cloud vendor that provides cloud services to multiple clients. All of the clients securely share the same hardware in the back end.

Private Cloud

A private cloud, on the other hand, is when the hardware is only used by a single company, which most of the time, but not necessarily always, also owns the hardware and datacenter. This is very close to the traditional datacenter model we always had, but in a private cloud, most of the time, IT bills the different departments based on the services that they use.

Hybrid Cloud

Next up, we have a hybrid cloud. The hybrid cloud is a combination of both public and private clouds. Often, there’s automation and orchestration between the two. Next up, we have the hybrid cloud, which is a combination of both the public cloud and the private cloud with automation and orchestration between the two.

Community Cloud

The last option is the community cloud. In a community cloud, you have a shared infrastructure between several organizations with common security, compliance, and jurisdiction concerns. We often see the example of a community cloud when governments from different countries set up a shared services division that hosts all of the IT for that government.

Now, let’s take a look at Azure and how that fits in. The easiest one is really the public cloud, as most Azure customers and offerings are in the public cloud model. Microsoft also has solutions for the private and hybrid cloud markets in its Azure Stack product family, which can be used for both connected scenarios, meaning hybrid cloud, as well as disconnected scenarios so you can run the same application inside of private cloud on your own hardware. The big advantage is that the tools, experiences, and app models you would have in your private cloud would be consistent with other workloads you might have on the public cloud, and this would also allow you to easily transfer workloads from your private cloud to the public cloud, whatever you decide to do so. Lastly, Azure also has offerings for the community cloud category. One of the most popular examples is probably the Azure Government, which is an Azure offering specific to government entities. You cannot simply register for it, you need to be a valid government organization and be approved for it. Azure Government is actually hosted in separate data centres from the public cloud and can handle data that is subject to government regulations and requirements, such as FedRAMP, DOD, CJIS, and more. Azure also has other community cloud offerings, for example, Azure China and Azure Germany, and from Microsoft, those are part of the sovereign cloud category, but from a cloud deployment model point of view, those are both community clouds.

Conclusion

First of all, we have learned what cloud computing is and how it enables companies to consume a compute resource, such as a virtual machine, storage or an application, as a utility, just like electricity, rather than having to build and maintain computing infrastructure in‑house. We have then learned about the cloud computing services. The three main ones are Infrastructure as a Service, Platform as a Service, and Software as a Service. And we have also looked at different Microsoft offerings for each cloud computing service model, from Infrastructure as a Service to Platform as a Service, and finally, Software as a Service. We have also looked at the different cloud deployment models, the most popular being the public cloud, where you have a cloud vendor that provides cloud services to multiple clients and all of the clients securely share that same hardware in the back end. A private cloud, on the other hand, is when the hardware is only used by a single company, which most of the time, but not always, owns the hardware and datacenter. Next up, we have the hybrid cloud, which is a combination of both public and private cloud with automation and orchestration between the two, and the Microsoft solution for it is also the Azure Stack. The last option is a community cloud, which is a shared infrastructure between several organizations with common security, compliance, and jurisdiction concerns.

Thank you very much for reading this artical.

Reference

Pluralsight Course: https://app.pluralsight.com/library/courses/microsoft-azure-cloud-concepts/table-of-contents

Posted on

Why Your Startup Needs a Tech Partner

How to move your project forward without an in-house team and CTO

We all live in a magical time, an era of innovation, in the age of unicorns. Everyone who reads tech news at least once in a while can’t help but get inspired by startup success stories. In reality, though, it turns out that building a tech company that will last is not as easy as it may seem, and stories of failure are much more common than journalists lead you to believe.

While there are sucssful start ups, as many as 70% of startups fail. Other stats can be even worse — consumer hardware companies fail more often, with a shocking 97% rate. Startup Genome analysts shows that 90% of all startups will sooner or later die. As bad as it sounds, there may be a way out. Instead of focusing on the sad side of entrepreneurship, let’s think of what can be done to prevent those failures. What can startup owners do to make their journey easier and more enjoyable? Is there someone to help them survive, concentrate on their goals, and succeed?

Why Startup Companies Outsource

At first glance, outsourcing is not a startup thing and is usually associated with big business. Yes, large companies have enough personnel and other resources to get their work done, but they often choose outsourcing as the best way to maximize their profit, increase work efficiency, and improve the quality of their products. On the other hand, startups, afraid of additional expenses, tend to cut corners constantly. The truth is startups should outsource as much as big companies do, if not more.

Many well-known brands have outsourced their development to get their business off the ground, and many of them continue to delegate at least part of their work. For example, Skype’s success would be impossible without three Estonian developers who created the company’s application back-end. Back in the day, one of the most popular corporate communication tools, Slack, outsourced the design of its web interface to British MetaLab, and as it turned out, it was a very good idea.

If we think about the long-term perspective for businesses, scarcity of the resources means that you have to prioritize. This is particularly relevant to IT-related tasks. Another important point is that newborn companies often don’t have enough hands to solve their challenging tasks effectively. A startup may have a brilliant idea, and its CEO may be very ambitious, but even the most talented specialist cannot build a company alone. The third problem follows from the fact that startup projects are often based on innovative business ideas. This often means a lack of know-how both in the development team and in the local market in general.

There are many other obstacles a startup may face both in the beginning and throughout their entire journey. They’re precisely the reason why startups should outsource. Let’s name the most challenging ones:

Starting fast

You may have the most innovative idea and be very passionate about bringing it to life. Yet, if you don’t get your product to market quickly, you’ve lost the game. If you deliver your product quickly, it gives you a big advantage over your competitors.

Scaling up

In the fast-changing competitive world, a business should always offer more today than it offered yesterday. This includes providing new services, serving more clients, or bringing fresh ideas to life.

Scaling your business, though, requires high-quality specialists capable of performing complicated tasks in a short period of time. In other words, you should scale your team first. Obviously, not all startups start to earn money at once, so they cannot handle the overheads of expanding their staff internally. Every new hire comes with onboarding time, purchase of office equipment, and requirements for renting additional space. Outsourcing eliminates all of these issues and allows businesses to expand their design, development, and QA staff.

Saving costs

Every penny counts, and this is especially relevant for a startup. Even if a startup is lucky enough to raise a big round of venture capital at the beginning of its journey, it should spend wisely. Sticking to reasonable budgets and reducing startup costs should always be one of the main priorities. At the same time, a startup can’t sacrifice the quality of its product as it can lose the game from the start. Therefore, the only viable option for startups is to develop a cost-effective approach in their work and pay only for what they really need.

Hiring top-notch specialists

No matter how passionate young entrepreneurs are and how much they want to do everything by themselves — their time and skill set is limited. Startup founders may be businessmen in nature, but this doesn’t make them programmers, designers, or project managers. They can’t write any code or create a polished visual concept. Sometimes a startup is entering a very niche industry or building a very complex product, and they need specific rare expertise necessary to perform the challenging tasks. Sometimes this expertise isn’t available locally. No matter what the cause, the truth is that a lack of hands can become a real problem for a young company.

Being flexible

What defines a real startup is their flexibility, agility, and the ability to scale an innovative business model confidently. Being a startup means maintaining a healthy workflow in stressful phases — adjusting the workforce according to the immediate business needs but still remaining focused on the main strategy and core tasks. This can happen before the product launch, when new ideas must be implemented quickly or when a startup is expanding its business and enhancing its growth. In other words, startups should embrace flexibility, so they can pivot when necessary, without things falling apart.

No matter how awful those challenges may look like, startups have good chances to tackle them successfully. The answer to many problems of a young entrepreneur is called outsourcing. Even if you are building your first startup, you don’t necessarily have to make every beginner’s mistake by yourself. But with no experience, how to avoid these mistakes in your own game? The simple answer is to find a technical partner.

Posted on

Understanding Microservices Architecture: Executive Briefing

The Challenges of Architecing for the Cloud

If you’re building a large modern enterprise software application, it’s really important that you get the architecture right. We have high expectations these days.

Performance and scalability

We want our applications to perform really fast and to be able to scale to meet demand without having to pay for compute resources we’re not using.

Resilience

We also want our applications to be resilient so that if there’s any temporary outages or failures, they don’t take down our whole system.

Easy to deploy and zero-downtime upgrades

And we’d like our applications to be easily deployable so that we can rapidly release new versions to meet changing requirements. On top of that, we’d also like the upgrades to our application to be seamless, without requiring downtime.

Code maintainability

For large applications, we need the code to be written in such a way that lots of developers can work on it simultaneously, without getting in each other’s way of breaking things.

Flexibility

And we want the codebase to be easy to evolve, allowing us to adopt new technologies and adapt to new requirements without the need for a major upheaval.

Observability

It’s also really important that our applications are observable, so that we can easily monitor them, checking that they’re working as expected and responding quickly to any problems in production, ideally even before our end users know there’s an issue.

Security

And, of course, We must have first-class security. If we’re storing valuable and sensitive data in the cloud, then it’s critical that we have extremely robust defences against hackers.

Now, that’s a pretty tall order. It’s not at all easy to design a software architecture that excels at meeting all of those criteria.

Microservices

And this is where microservices comes in. Microservices is an architectural style that’s rapidly grown in popularity over recent years and can help a lot in meeting the challenges we’ve just mentioned. In this executive briefing, We going to introduce you to the main characteristics of microservice architectures, and we’ll learn about what benefits they can bring. But we’ll also be very realistic about some of the challenges that will be introduced if you decide to adopt a microservices architectural style, and we’ll see how we can overcome those challenges.

What Are Microservices?

Before we go too much further, we need to define what exactly do we mean by a microservice. There isn’t really an official definition, but there are some key characteristics that all microservices should have. A very simple definition is that microservices are small autonomous services that collaborate to form a broader application.

Microservices are small autonomous services that collaborate to form a broader application

Let’s go into a little bit more detail about exactly what we mean by that.

Independently deployable

It’s important to understand that microservices should be autonomous, this means that they’re independently deployable. In other words, you can upgrade just one microservice to a new version without having to upgrade all the others at the same time.

Microservices own their own data

Microservices should also own their own data, that means each microservice has its own independent database rather than sharing a database with other services.

Synchronous or asynchronous API

Each microservice exposes an API, it’s quite often an HTTP API, but asynchronous communication with messaging is also commonly used. Anyone who wants to access the data owned by a microservice must do so via its API, which is essentially its public interface.

Single responsibility

Each microservice should have a single, well‑defined responsibility, usually organized around business capabilities. Because microservices have a single responsibility, they ought to be relatively small, hence the name Microservices.

Microservices should be small

We’re trying to avoid creating gigantic services that have huge codebases and do everything, and this means that a microservice can be built and maintained by a small team of just a few developers, and in some ways, this is one of the most compelling arguments for microservices, it gives us a way to scale our teams. And because microservices are autonomous, these teams are free to make progress and release new versions of their microservice without being held up by other teams.

Microservices enable us to scale our teams

What Problems Do Microservices Solve?

We’ve talked a bit about what microservices are, but why do we need them? What problems are they trying to solve? This is a very important question to answer because microservices aren’t necessarily the right approach for every application.

Microservices aren’t necessarily the right approach for every application

Monolith

Let’s start by describing an architectural style that microservices are often contrasted with. A software architecture where we implement all the functionality inside a single large application with a single code base and all our data stored in a single database is often described as a monolith.

Now although the term monolith is sometimes used quite dismissively, there’s nothing necessarily wrong with a monolithic architecture. In fact, it can have many benefits.

Benefits of “Monoliths”

Code is easy to navigate

For example, if all your code is in one place, then within your IDE, you can find the code and debug directly into it for all the features of your whole application.

Straightforward deployment

And if everything builds into a single executable, then deployment may only involve updating one single server with the new version of the code, which is relatively straightforward.

So there’s a certain simplicity that comes with a monolithic architecture, which can be very beneficial. However, it’s very common to start running into serious problems as your application grows over time.

Monoliths can cause serious problems as applications grow over time

Challenges of “Monoliths”

Codebase grows larger and complex

First of all, over several years, your single code base may have grown to millions of lines of code, making the application as a whole very unwieldy and complex to work on. If you’ve got large teams of developers working on a project like this, it’s very common to find them treading on each other’s toes and making conflicting changes.

Can get stuck on legacy technology

With monoliths, you’re likely to get stuck on legacy technology, and that’s because the programming framework you originally built your monolith with will eventually become obsolete. But by that stage, there’s often so much code that migrating the whole thing away to something more modern is too large a task to attempt.

Deployment requires downtime

Although deploying a new version of a monolith tends to be relatively straightforward, it often requires some downtime, with the whole application needing to be stopped to allow the server to be updated before the new version can start up. But in the modern era of cloud‑based computing, our expectations are that applications will continue to run without noticeable downtime even during an upgrade.

Scalability can be difficult

Scalability can also be a real challenge with monoliths. If your application is under heavy load, you can scale up by upgrading to a more powerful server. But scaling up can only take you so far. To go further, you also need to be able to scale out where you run multiple instances of your application on many servers. But in order to do that, you must ensure that your entire application has been written to be stateless. And, unfortunately, in many monolithic applications, that just isn’t the case.

Tight coupling reduces flexibility

Finally, it’s very important that our applications are flexible and can easily adapt to changing business requirements. But without great care, monolithic codebases tend to become very tangled and tightly coupled due to their nature of having all the code in one place. And that can really hinder progress.

And all of these problems that you can run into with monolithic architectures are the reason why, in recent years, many companies have chosen to start moving away from this approach and towards microservices.

Microservices can help address the challenges of monolithic architectures

Of course, We have oversimplified things here. There is, in fact, a whole spectrum of architectural options all the way, on the one hand, from having a genuine monolith through to maybe a more distributed service‑oriented architecture all the way through to microservices.

But now we’ve identified some of the problems we can run into with monoliths, let’s look in more detail about how microservices can help solve these problems.

How Can Microservices Help?

Let’s look now at the ways in which microservices can address some of the challenges that we’ve identified with monolithic architectures.

Reduce code complexity

For one thing, microservices can be a helpful way to avoid our codebase becoming very tightly coupled and complex. By breaking responsibilities out into their own microservices, each of those smaller codebases is much more simple and focused, which makes for code that’s much easier to maintain and evolve.

Freedom to choose the right tool

Breaking our application up into microservices also gives us the freedom to choose the right tool for the right job. For example, one microservice might use a document database, while another uses a relational database.

Small, independent development teams

Each microservice can be owned and maintained by a small team, and this greatly reduces the problems associated with having too many developers trying to work on the same code base at the same time.

Migrate to new technology more easily

Microservices also allow us to migrate to new technology more easily. Rather than having to update everything in one go, each microservice can be upgraded individually as needed.

Possible to rewrite if necessary

In fact, their small size means that microservices can also be completely rewritten if necessary, which is typically cost-prohibitive with a monolithic application.

Improved resilience

Microservices can also help us achieve a more resilient architecture that copes better with transient failures. Even if one microservice is temporarily unavailable, it’s possible for the rest of the system to keep working.

So we no longer have a single point of failure where one problem takes down the whole system, and this characteristic of microservices helps us to achieve high availability even during upgrades.

Support continuous delivery

The microservice architecture supports continuous delivery where we can frequently and safely perform rolling upgrades of individual microservices, allowing us to deliver new functionality quickly without requiring periods of downtime. With microservices, we can scale specific capabilities independently.

So we might, for example, dedicate several virtual machines to share the load for one particularly busy microservice, while other microservices may only require a single instance.

Reusability

Finally, when you create small, focused microservices with clear responsibilities, you often find some of them can be reused in other contexts, essentially becoming building blocks, enabling you to innovate faster.

And those are just a few of the benefits that microservices bring, and hopefully, that gives you an idea of why they’re becoming so popular.

What Are Some Challenges of Microservices?

Now, so far, We’ve been very positive about microservices and talked a lot about the benefits they can bring. But it’s important that we make it very clear, microservices aren’t magically going to make all of your problems go away. In fact, microservices can bring some really significant technical and operational challenges, and you need to be aware of those before choosing to adopt a microservices architecture. Let us give you a brief overview of some of the key challenges you’re likely to run into sooner or later on your microservices journey.

Defining microservice boundaries

First of all, in order to get started with microservices, you need to come up with a way of dividing up responsibilities between those microservices. That might sound relatively easy, but it’s actually quite tricky to make good decisions here that will serve you well in the long term.

Difficult to make good choices

If your microservice boundaries are in the wrong places, you can end up with a poorly performing system, as there’ll be lots of chatty network communication between microservices and the need to fetch data from multiple different databases. You can also miss out on the benefits of having small, independent teams of developers who take ownership of microservices if your division of responsibilities means that most new features end up requiring all the microservices to be updated at the same time.

Apply “Domain-Driven Design” principles

A good way to avoid this pitfall is to learn about domain‑driven design. This approach encourages us to identify what is called bounded contexts within our application. These are natural boundaries of business‑focused responsibilities, and often it makes sense to create a microservice for a specific bounded context.

Development workflow

Another challenge is that when you have many microservices, it can become really difficult for your developers to work effectively on the project. Do they need to fetch the source code for all the microservices and build them all and run them all locally? That can be a very slow and error‑prone process. The secret here is to find ways of automating and streamlining the development experience. Making use of Docker containers is one great way of achieving this, as developers can use docker‑compose to easily start up all the microservices locally without having to build them first.

The deployment must be automated

It’s also critical that you automate the deployment of your microservices. You might be able to get away with a manual deployment process for a monolithic architecture, but when you have many microservices, it’s simply too time‑consuming and error-prone to deploy each one manually. Instead, you should consider implementing continuous delivery principles so that every time a new version of a microservice is released, it can be published into a production environment with minimal effort.

Operational insight

Another way in which microservices can be a step backwards compared to monoliths is getting the operational insight you need to know what’s going on and what’s going wrong in a live production system. With a monolith, there’s often just one server to monitor and one place to view all the logs. But with microservices, you have many processes running on many virtual machines and each outputting their own logs. And this means it’s well worth your time investing in aggregating all the logging, telemetry, and metrics into a single centralized dashboard that can be easily monitored.

Microservices can get bloated

Finally, if you don’t take care, over time it’s quite possible that some of your microservices will get bloated and take on many more responsibilities than they ought to have, making them more like the monoliths that we were trying to get away from in the first place.

So, there are several challenges that you do need to be aware of before deciding to embrace microservices, and you need to have a plan to deal with them. Fortunately, you’re not alone in this. The challenges of building, deploying, and monitoring microservice applications are pretty much the same whatever business context you’re in. And because of that, we’ve seen many tools and frameworks emerging over the past few years which have the explicit goal of making it easier to build and run microservice applications.

Reference

Pluralsight Couse Microservices Archtecture

Posted on

Why Do I Need a Website for My Small Business?

Today you can have a website for pretty much anything—from crowdfunding campaigns to pet hamster fan pages. But for some reason, an estimated 30-40% of small businesses have been slow to get online. What gives? 

In surveys, many business owners say they don’t have the skills, the time, or the money to build a website. But a surprising number say that they don’t need a website in the first place, either because it’s not required or because they use social media instead.

That idea is changing quickly though, especially as coronavirus makes in-person business more difficult.

We’ve put together some specific reasons why your small business should have its own website. If you’re a small business owner who is still on the fence, read on!

  1. Customers now expect businesses to have websites
  2. A website makes you look more reputable and trustworthy
  3. You can control information and branding
  4. You can sell products online
  5. You can find new local customers near you

Customers now expect businesses to have websites

Now more than ever, customers want to be able to find information about you from your company website. Most consumers do research online before they make a purchase, even if it’s to buy something from their local shop. If you don’t have a website, it sends a message that your business is stuck in the Dark Ages, that you’re not open anymore, or that you’re not interested in finding new customers—and those are certainly not messages you want to send! 

A website makes you look more reputable and trustworthy

Consumers are learning to be pretty savvy when they research online. In fact, 75% will judge your credibility based on your website design. That’s why it’s so important to have a modern, up-to-date website with a custom domain and other markers of trustworthiness. A website also shows that you are open for business during a time when there is a lot of uncertainty.

You can control information and branding

User reviews and comments on other websites are great, but shouldn’t you have the final say about how your company is presented to the public? Having a website for your company instantly creates an official presence on the internet so that you don’t have to depend on others speaking for you. And you can make it look exactly the way you want, with your own logo and branding.

You can sell products online

Online sales were on the rise even before COVID-19 kept everyone stuck at home. And these trends are expected to continue after businesses reopen to customers. So even if you don’t think of yourself as an “e-commerce” business, you can still use an online store to benefit your offline business.

It can help supplement your income when you’re closed in-person and attract new customers who will now be able to find your services and products via Google and other search engines.

You can find new local customers near you

A website isn’t just for finding customers across the globe—it’s an essential tool for attracting local customers too. Many Google searches are people looking for something right near them. That’s especially true of mobile phone users who might be looking for a store, restaurant, or other services while they’re on-the-go. If you don’t have a mobile-friendly web site, you’re missing out on an opportunity to catch those visitors when they’re right in your neighbourhood. 

Conclusion

The case for having a website in today’s world is very strong. Almost all the businesses surveyed said they planned to have a website by the end of the year. Are you part of this group? Make it a reality by signing up for a free Jimdo website today, and see how easy it is!