DevOps – Configuration Management

Configuration management is the management of the configuration of all environments for an application.

Both Infrastructure as Code (IaC) and configuration as code fall under configuration management, and both relate to defining or scripting for environments:

  • IaC – entails defining environments as a text file (script or definition) that is checked into version control and used as the base source for creating or updating those environments.
  • Configuration as code – define the configuration of your servers, code, and other resources as a text file (script or definition) that is checked into version control and used as the base source for creating or updating those configurations.

SaltStack or Ansible in CI/CD accelerates configuration management and deployment.

Benefits of configuration management:

  1. more maintainable
  2. Fewer locations to update
  3. Fewer mistakes
  4. More secure
  5. More reliable

DevOps

Best definition of DevOps –  the union of people, process, and products to enable continuous delivery of value to our end users. What is DevOps – Donovan Brown

Core values of DevOps:

  • collaboration across a multidisciplinary team with a common goal, common metrics, common notion of improvement and they need to work together as one
  • process focus on more value and less waste (remove manual handoffs, delays waiting times) and doing more for the end users
  • tooling – provides automation, eliminates rework, eliminates mistakes and get feedback

observeorientdecideand act

  • focus on the velocity of this loop

To be stable and reliable you don’t need to move slower but you need to build resilience into your systems and you need to get used to do changes more frequently.

The role of an IT Manager is critical in a DevOps mindset. There is need for a middle layer that translates business needs on the execution ground.

One of the core values of DevOps is a shortened release cycle.

DevOps practices:

  1. Configuration management
    • what we are deploying, how we are deploying it, what is the configuration of what is going into production
  2. Release management
    • how to build a release pipeline that we can trust
  3. Continuous integration
    • testing the code, compile it at every single check-in
  4. Continuous deployment
    • getting it out in a testing environment at a very least,
  5. Application performance monitoring
    • production monitoring and getting performance error and usage information
  6. Test automation
    • automate all types of test (deployment, integration, user experience, UI)
  7. Infrastructure as code
    • when we deploy the code we have a related infrastructure and that infrastructure is checked in the version control as well

DevOps habits: – help drive the right culture

  1. Team autonomy and enterprise alignement
  2. Rigorous management of technical debt
    • take time in the schedule and reduce it
  3. Focus on flow of customer value
    • a mindshift for development and operations
    • dev+tester+it – gets first piece of feedback when the customer uses that feature
  4. Evidence gathered in production
    • when looking in production try to figure out new ways of doing things – it could lead to a hypothesis driven development
  5. Live site culture
    • there is no place like production
  6. Managing infrastracture as a flexible resource

 

Objects and data structures

A class should not push its variables out through getters and setters. It should expose abstract interfaces that allows its users to manipulate the essence of the data without having to know its implementation. We want to express data in abstract terms.

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. Object oriented code makes it easy to add new classes without changing existing functions.

Not everything is an object.

The Law of Demeter – a module should not know about the innards of the objects it manipulates. A method  of a class C should call only the methods of these:

  • C
  • an object created by f
  • an object passed as an argument to f
  • an object held in an instance variable of C

Talk to friends, not to strangers.

Data Transfer Objects – a very useful structure with public variables and no functions used especially when communicating with database which often become the first in series of translatio stages that convert raw data in a database into objects in the application code.

Active Records – a special form of DTO with navigational methods like save or find and are direct translations from database tables.

Objects expose behavior and hide data making it easy to add new kinds of object without changing existing behaviors. It also hard to add new behaviors to existing objects.

Data structures exposes data and have no significant behavior. That makes it easy to add new behaviors to existing data structures but makes it hard to add new data structures to existing functions.

Choose the right approach:

  • objects – the flexibility to add new data types
  • data structure – the flexibility to add new behaviors

 

 

Azure multi-region deployments

The customers demand the highest performance in availability and their expectation is that the application will run even if even a data center may be down.

We can deploy publish the application into a second region that can be even on another continent.

Azure Traffic Manager will route clients to the one of the region where we deployed. It can be configured:

  • to route the clients to the lowest latency region for that specific customer
  • use geographic routing, for example, a customer from Europe will use a data center from Europe.
  • add a standby region –  route clients to the standby region where it is something wrong with the primary region.

Geo-replication for our data – Azure SQL and Document DB replicate data around the world. For example, you can have a primary database in the first region and a secondary database in the second region. All the operations committed to the primary database will be replicated (asynchronously) to the second database.

Web application + App Service

When an Web application or an API needs to be published to Azure => App Service – Platform as a Service – no need to take care of the virtual machine or the OS. The deployments will be nearly instantaneous because all the infrastructure is already in the place so we can publish directly from the source code.

An App Service plan can be used to scale vertically to add/remove cores or to scale horizontally to add/remove instances. Or use auto-scale.

Use diagnostic tools, metrics tools, debugging tools (even a remote debug session and step through code running inside an App Service) instead of connecting remotely and inspect the environment.

Deployment slots associated with an app service (Staging, QA, Production).

Storage account (BLOB Storage) – store log and diagnostic files, user uploads, application static content (images, videos, script and CSS files) – this way the content will be pushed into Azure Content Delivery Network

Database – Azure SQL (relational model) or Document DB (storing documents) or both. The details (patches, logs)  are handled by Azure (database as a service).

To talk about – Azure Resource Group – encapsulates all these resources (App Service, App Service Plan, Storage Account, Azure SQL) – a logical container for resources – grouping all the application resources into a single group will make it easier to manage the Azure services.

 

Clean code #2 Naming

We are doing a lot of naming so we should do it well.
The name should tell why it exists, what it does and how it is used.

Some rules for a good naming:

  • use intention revealing names
  • avoid disinformation (using inconsistent spelling is also disinformation)
  • make meangful distinction
  • use pronounceable names (programming is a social activity)
  • use searcheable names
  • no hungarian notation
  • no member prefixes
  • pick one word per concept
  • don’t use funny names

Clarity is the king – professional programmers understand that, smart programmers may not.

Clean code #1

In the days of Scrum and agile the focus is on quickly bringing product to market.

In software 80% of what to we is called  maintenance – the act of repair. Such care and ongoing refinement never come to an end.

I read doing major softer chunks from scratch every seven years or so

Name a variable using the same care with which you name the first born child

Be honest to the code, to your colleagues about the state of your code and be with yourself about your code.

Learning to write clean code is hard work.

Code will never end because code represents the details of the requirements and specifying requirements in such details a machine can execute is called programming. There always will be code.

Interfaces fundamentals – notes

An interface is a group of public members that defines a contract. It is a group of related functions that can belong to a class or struct. In order to fulfil the contract you must supply implementations for all of the interface members. The compiler will enforce the implementation.

An abstract class can contain members with different access modifiers. Interfaces contain only public members and only properties, methods, events and indexers. Constructors and destructors are specific to a particular class, they don’t belong in a general contract.

Abstract class biggest strength is that it can contain implementation code that is shared among all of child classes but its biggest disadvantage is that it can inherit only one base class.

Interface biggest strength is that you can use any number of interfaces but there is no shared code implementation, it contains only definitions.

Updating an interface – Adding or removing members will break implementation or break usage. You can use inheritance to add an interface.

Interface explicit implementation – when two methods have the same name and parameters but the return type is different.

 Program to an abstraction (interface) rather than a concrete type (class).

Using interfaces makes the code maintainable, extensible and easily testable. When using an interface you don’t need to care about the implementation details.

The repository pattern – mediates between the domain and data mapping layers using a collection like interfaces for accessing domain objects. It separates the application from the data storage technology.

Interface Segregation Principle – the I in SOLID. Clients should not depend upon methods that they do not use. Interfaces belong to clients, not hierarchies. Granular interfaces that include only the members that a particular function needs.

Example: the class List<T>. It implements Ienumerable<T> for iterating over a collection, data bind to a list control,use linq,  ICollection<T> for adding and removing items in the  collection, counting and clearing it, IList<T> for more control.

Dependency injection – the goal is to create loosely coupled code by making something else responsible for dependent objects. Patterns: Constructor Injection, Property Injection, Method Injection, Service Locator. Use a Dependency Injection Container.

Mocking – Provide behaviour  for the methods we plan to use. Use a Mockup Framework.

Object Oriented Programming fundamentals – notes

Object != Class
A class provides the definition of the object type. It defines properties and actions.
An object is an instance of a class
The object variable is the variable that references the object result of the instantiation. It holds the state of the object. It retains the values of its properties.
Objects only exits at runtime.

A class – a cookie cutter
An object = a cookie made by the cookie cutter

Business object, entity

A business object is a class specifically defined for solving a business problem
An entity is anything from the real world that is significant enough to be represented as a class in the application

OOP
Object Oriented Programming is  an approach to build applications by focusing on objects that interact cleanly with one another in a way that is flexible, natural, well-crafted and testable.

In order to build to solve a real problem

Identify classes
Separate responsibilities
Establish relationships
Leverage reuse

The 4 pilons of OOP

Abstraction is a concept, a way to think: define appropriate classes by focusing on what is important for a purpose. Appropriate abstractions depends on the requirements of the application.

Cohesion
Collaboration – « uses a » – one class uses another class. Example, orderRepository uses the Order class to display the order or to serialise

About .Net Standard

The .NET ecosystem is available as a stack for any kind of developer (mobile, desktop, cloud, Windows or non-Windows). Every platform has a different base class library so if you want to encapsulate parts of your application (or create a new library ) that will run on all platforms you will need implementations for each platform. So, the solution was to unify all these base class libraries into one base class library called .NET Standard. This way, a developer can master only one base class library, the code reuse targets a big surface area and the .NET Standard can grow faster without updating any platforms.

.NET Standard is a specification and in the same time a type of class library with a set of APIs that the current and future platforms have to implement.

.NET Standard will replace Portable class libraries.

Higher versions of .Net Standard will incorporate all APIs from previous versions.

Specific platforms of .NET implements specific version of .NET Standard.

How do you choose what version of .NET Standard to target?

  • the higher the number of the version of .NET Standard is the more APIs you have available
  • the lower the number of the version of .NET Standard is the more platforms you can run on (the more .NET platforms implemented the standard)

Read more about .NET Standard: https://github.com/dotnet/standard

The catalog of APIs – https://apisof.net/