Cloud as a Story - Vunvulea Radu

 Let's talk about Azure autoscaling feature. I found often people that are configure autoscaling without understanding what each item from the configuration panel represents.  THE STORY One of my friends called me a few days ago telling me that the scaling configuration of the App Service that he manages does not work as expected and there might be a bug. It is not common to find such issues on autoscaling capabilities, because of this I suspected from start a miss-configuration. The reported problem was related to how fast the no. of instances are growing. After reviewing the configuration I notified that the cooldown time period was configured wrong. AUTOSCALING INSIGHTS Let's start with an example. We have autoscaling configured for a web app that is using Standard App Service Plan. The scaleout is configured with the following configuration: When the average CPU level is greater than 70, for more than 40 minutes, increase count with 3 When the average CPU level is greater ...

This week I had the opportunity to talk about microservices during Connect.IT. The main topic that I wanted to cover was related to the things that we forget about when we build a solution on top of microservices. The online event was organized during the afternoon and gather people especially from Targu-Mures and Cluj-Napoca. You can check below the presentation content: Title : THE MICROSERVICES CONFUSION Abstract :  Nowadays, every new project that we start is around microservices. You cannot build anymore a simple solution that goes into production for a 2-week time frame. Many times we grow the project complexity because of the current IT trends without thinking about what we need. T he focus of the session is around microservices and what is the impact of it during development, automation and operation phase. The purpose is to identify the balance between the size, number and complexity of the services taking into account the delivery time and budget, especially during ...

As you already know, the cloud is already a commodity and is part of the most software solutions available on the market nowadays. Nevertheless, if you do quality assurance or testing activities on cloud application, you have a lot of challenges.  QA and Testers are ignored by cloud The expectation from the marker is to have people on these roles that know how to test applications and to run different procedures to ensure that the systems run as expected. You might say that testing an application that is running inside the cloud is the same as on-premises. It might be similar but not the same. Things like: Logs locations Metrics repositories New interaction with storages Access to resources A point in time restore Mechanisms to run different tests (e.g., DDoS attack) Security ... and many more are different. Personally, I would even say that from the cloud point of view, quality assurance (QA) and testers are left behind and ignored.  If we take a look at the learning paths or...

In the last week of July, I had the amazing opportunity to be invited by Azure Days  to deliver a session about Azure Form Recognizer. I talked about how we can build a system that can identify the teammates that are flying to the same destination as you using airplane tickets.  From the logistical point of view, things were awesome, even if it was an online event. We had channels used to communicate with other speakers, with the Azure Days team, and with the attendees. Everything was perfect, except one thing - my neighbor decided to mow the lawn during my session :-), because of this for a few seconds there was background noise, but it was fixed fast, by closing the windows. You can check below the details and recording of my session: Title : Demystifying messaging communication patterns Abstract : Kubernetes together with microservice architecture provides perfect support for the new generation of software solution. Even so, Kubernetes clusters need no be able to ...

A few days ago I had the amazing opportunity to deliver a technical session to the IT community from Medellin. It was my second time when I deliver a session to Medellin. In comparison with the session from last year, this time it was remotely because flying is not an option nowadays.  I talked about microservices, the future of serverless and microservices and what are the mistakes that people are doing when they start to use microservices. If you want to check my session you can find the details below. Title :  The microservices confusion  Abstract : Nowdays, every new project that we start is around microservices. You cannot build anymore a simple solution that goes in production in 2 week time. Many times we grow the project complexity because of the current IT trends without thinking about what we need. The focus of the session is around microservices and what is the impact of it during development, automation and operation phase. The purpose is to identify the ...

One of the most common cloud projects time nowadays is cloud migrations. I found challenging when I start a discussion related to migrations because each person has a different understanding of each migration strategy.  The main six types of migration strategies are: Rehosting Replatforming Repurchasing  Refactoring Retire  Retain On paper, things sound easy, but once you start to dig into the problem, you realize that most of the people say that they are doing all of them at the same time on all the projects without knowing the differences between them. In this article, we cover 3 main things related to cloud migration (1) Definition (2) Examples and (3) Comparison between different strategies. Retain You are in the phase when you are not ready to do the migration. You might identify other pains inside the current business or inside your IT landscape that have a higher priority. In this case, you cancel the migration for now and focus on another area. Take into account t...

There are cases when we cannot use cloud service as in the book. Even if in theory the mapping between the technical needs and the functionality of the cloud service is perfect, we could have external factors that influence the way how we design the solution.   You should remember all the time to check all current context, team shape, and client preferences before building a solution. Context Imagine that you need to build a solution that would fetch data from an Azure SQL Database, do some transformation and push content to an on-premises database over HTTPS.  Initial Solution When you read the high-level reqs you already see an ETL solution, that would be translated into an Azure Data Factory that load data from SQL Database, to some transformation and make HTTPS requests.  Team shape Azure Data Factory integration with SSIS packages enables us to build an ETL seamless, using the team knowledge that already exists on SQL Server and SSIS. When the team technology st...