Cloud as a Story - Vunvulea Radu

We all make mistakes. Sometimes are small with no impact on business continuity, sometimes are bigger and can impact the business. A few years ago I was involved indirectly in a project where a wrong decision generated not only a large amount of money to be lost, but also still have impact on the current business and there is a high risk to affect the business continuity. I decided to write this post as a lesson learn for all of us and to try to avoid making the same mistake, especially in this era, where SaaS is the preferred option, buying licenses for existing solution is better and developing your own – without analyzing the impact and what shall be done if you want to change the provider. Overview Don’t understand me wrong. I’m a big fun of SaaS and buying then in-house development. From my perspective, this is the right solution. It is the right solution for companies that have the right people around them. People that are aware of dependencies, that the system will become one...

Small things make the difference - Azure Billing Alerts  In the last 3 months a part of the team was blocked with some urgent tasks. Because of this they didn’t had time anymore to review the Azure Services Instances that are running under the development and testing subscription. The rest of the team didn’t check the costs and/or review the services that are running on Azure. In the context where the people that used to check this were blocked with other tasks generates cost that are 2 time more than the normal ones – even if only half of the team is working in this time period on development. Of course the best solution was that somebody would check this and the responsibility to be passed to another person, but it didn’t happen. A better approach is to have a team that knows that running services on a cloud provider generates costs and they should all the time review what services they are using and turn off the ones that are not used. But this didn’t happen of course. ...

At the beginning of this month I had the opportunity to be invited as speaker at a local ITCamp Community event in Timișoara . This kind of local community events are so great because you can meet greeat people, that are working for different clients and industries. In this way you can take the real pulse of the IT industry and what is happning in different cities. The event was organized by ITCamp Community . At this event, there were 5 sessions that talked about different things like mobile development, Azure SQL, security, system center and microservices. At this event I talked abot Service Fabric and how we can use it to develop microservices solution not only for Azure, but also for on-premises – running them on Windows or Linux. Below you can find more information related to my presentation and some pictures from the event. Titile: Azure Microservices in Practice Abstract: In this session we will take a look on Azure Service Fabric and how we can create a web application us...

In the last post we talked about Cold Storage tier. Together we identified what are the main features and advantages of their tier. In the same time we discover that there are some things that we need to take into account such as the price of switching between one tier and another or the extra charge that is apply when we replicate the Cold Storage content to another region. This post is presenting different use cases where cold storage tier is a better option to store content. Also, cases when cold storage might not be the best choice will be taken into consideration. Archiving Logs and Raw data Because of different requirements we might need to store content for long period of time – 1y, 5y or even 20y. For this scenarios we need to identify a cheap location where we can store this data, with a minimum cost and in the same time to be sure that the content will not be lost or damaged after a period of time. A good example is audit logs, that needs to be stored more than we can i...

In this post we will talk about things that we need to consider if we want to use Cold storage of Azure Storage. This post we’ll be followed by another one that will present use cases when cold storage tier is useful and how we should integrated it in our system. (Part 2) Azure Storage - Cold Tier | Business use cases where we could use it Overview Cold storage tier of Azure Storage is a new tier that is available for Azure Storage for data that needs to be persisted for long time with minimum costs. This tier should be used when data is not accessed frequently. In comparison with Hot tier, cold storage latency can be a little bit higher, but still it is in milliseconds. Azure Storage contains multiple types of storages like Azure Queues, Azure Tables, Azure Blobs (block blob, append blob and page blob). Unfortunately, their tier is available only for block blob and append blob. It means that we cannot store an Azure Table or a Page Blob in the cold tier. The Storage Account that...

This week I was involved in a migration of an existing project that was written on Java stack to Azure. The current solution is using different technologies like Oracle DB, HA Proxy, Apache Tomcat, Elastic Search, Load Balancer and so on. There are around 5-6 different out of the box applications that are running around the solution. Objective The main purpose of the workshop was to understand the current architecture, how different components communicate between each other and what are bottlenecks of the current solution. The expected output of this workshop was a first draft of migration plan from on-premises to Azure. As usually, I’m done my homework before. I already had in mind different approaches using not only Azure VMs, but also Web/Worker Roles, Docker and Service Fabric. I didn’t know the current architecture, so I tried to sketch some possible solutions. Current solution The purpose of the solution is to increase the security of user identity by offering a additional...

Usually I don’t write posts about this kind of things, but last week I saw an update that makes our life better, especially if we are working with Service Bus or Event Hub. If you had the opportunity to work with one of this messaging/event system and when to production with them, I’m pretty sure (99.99%) that you had at least one exception from the messaging system that was very vague. A large system is not using only one Topic or Queue from Service Bus. But in the logs you can end up easily with a super duper generic exception, where you might not have all information about namespace, resource and so on. Because of this you start to write in the logs information from the ‘connection’ class to be able to log all the information that are needed. Once you get an exception from Service Bus, you usually check the status of the service, look inside the code and try to find our what is the root problem. Sometimes you find the problem and you are able to fix it. I’m happy in the moment w...