A data-driven organization acquires, processes, and leverages data in a timely fashion to create efficiencies, iterate on and develop new products, and navigate the competitive landscape.
Author wrote also:
There are many ways to assess whether an organization is data driven. Some like to talk about how much data they generate. Others like to talk about the sophistication of data they use, or the process of internalizing data. I prefer to start by highlighting organizations that use data effectively.
When you send a request to somewhere that uses your ip-number to whitelist, your ip number becomes important to know. It is pretty simple when you do this on your laptop where you can open up a browser and find your outbound ip-number in Google. When you run your request within an Azure Web App which is running on an ASP, you might want to open up a console in Azure Portal and use the following PowerShell command:
The goal of microservices is to sufficiently decompose the application in order to facilitate agile application development and deployment.
The following is based on the book Microservices from Design to Deployment from NGINX. My goal is to know the difficaulties that this inevitable is bringing with in order to be prepared for.
The Drawbacks of Microservices
One drawback is the name itself. The term microservice places excessive emphasis on service size. While small services are preferable, it’s important to remember that small services are a means to an end, and not the primary goal.
Another major drawback of microservices is the complexity that arises from the fact that a microservices application is a distributed system. Developers need to choose and implement an inter-process communication mechanism based on either messaging or RPC. Moreover, they must also write code to handle partial failure, since the destination of a request might be slow or unavailable.
Another challenge with microservices is the partitioned database architecture. Using distributed transactions is usually not an option, and not only because of the CAP theorem. They simply are not supported by many of today’s highly scalable NoSQL databases and messaging brokers. You end up having to use an eventual consistency-based approach, which is more challenging for developers.
Testing a microservices application is also much more complex. A simple test class for a service
would need to launch that service and any services that it depends upon, or at least configure stubs for those services.
Another major challenge with the Microservices Architecture pattern is implementing changes that span multiple services. Fortunately, most changes typically impact only
one service; multi-service changes that require coordination are relatively rare.
Deploying a microservices-based application is also much more complex.
Each service will have multiple runtime instances. That’s many more moving parts that
need to be configured, deployed, scaled, and monitored. In addition, you will also need to
implement a service discovery mechanism that enables a service to discover the locations
(hosts and ports) of any other services it needs to communicate with.
You can do more with less by reducing your design to its essence, and solving for distractions, not discoverability. Create a clean and purposeful experience by leaving only the most relevant elements on screen so people can be immersed in the content.
Be great at something instead of mediocre at many things.
Put content before chrome.
Be visually focused and direct, letting people get immersed in what they love, and they will explore the rest.
Inspire confidence in users.
Desktop browsers have quite a lot of chrome (menus, options, status bars, and so on) that is only sometimes useful. Typically, however, users open a browser to see a webpage, not to interact with the browser. Moving commands off the browser chrome and into the app bar or into charms helps users focus on what they care about.
Even though you “could” solve a problem by inheriting, see if there’s another option that doesn’t require you to inherit and compose your object of other helper object instead.
The above statement sounded so sophisticated when I read it first, that I wanted to put it in my blog. Yet there is something deep in my heart that tells me: don’t through away your years of experience and achievements gained by reusing objects through inheritance.
When 2 classes, let’s say Car and Vehicle implemented as follows: publicclassVehicle
Debug.WriteLine(“Vehicle is driving.”);
publicclassCar : Vehicle
Debug.WriteLine(“Car is driving.”);
By default the new implemented Drive method in the Car class hides the implementation in vehicle for any reference of Car type. So the following instances are expected:
Vehicle v = newVehicle();
// output : Vehicle is driving.
Car c = newCar();
// output : Car is driving.
But the next one might cause unexpected situations when the construction occurs in a method far from calling the drive method.
Vehicle x = newCar();
// output : Vehicle is driving.
The output for the last call (Vehicle x) changes to “Car is driving.” when the Drive method in Vehicle is defined as virtual and in the Car defined as override.
Looks like the problem is solved.
But sometime I have a factory class creating some instances for me and I simply declare my variables and request for an instance:
Vehicle x = Factory.GetBMW();
This means that the place I use the instance might have no knowledge of how the instance is created and might not even know how they are implementing the Drive method.
For me, the ideal situation might be when I have a reference to a class of type Vehicle, I like it to drive as Vehicle. And when I want to have a Car that drives as a Car, I will define my reference as a Car.
Vehicle x = Factory.GetBMW(); Car y = Factory.GetBMW(); x.Drive(); y.Drive();
I can see that my point might not be important for BMW factory and they would rather to create a Car that drives the same way, no matter who is driving it.
The Composition over inheritance suggests that Car and vehicle does not inherit from each other. To make sure that they both are sharing functionality, the BMW class needs to implement both interfaces.
Let’s say that the following code is where we like to achieve: