Санкт-Петербургский центр ИТ, блог

Роль привязок в Azure Functions

Thu, 30 Sep 2021 08:21:52 GMT

Что такое привязки?

В Azure Functions привязки ввода и вывода используются как способ подключения ресурсов к функциям, а данные из Привязок передаются как параметры.
При выполнении функции, привязки для вывода - ресурсы, которые записываются в вывод функции. Для дальнейшего использования нужно определить атрибут привязки для ввода к методу функции.

Как привязки работают в функциях библиотеки класса?

В функциях библиотеки класса привязки настраиваются с помощью декоратора методов и параметров функций, используя атрибуты С#, например:

[FunctionName(nameof("FunctionName"))]

public async Task Run([EventGridTrigger] EventGridEvent[] eventGridEvents,

[EventGrid(TopicEndpointUri = "TopicEndpoint", TopicKeySetting = "TopicKey")] IAsyncCollector<EventGridEvent> outputEvents,

ILogger logger)

{

// Function code

}

В коде выше есть функция, которая запускается сеткой событий и использует привязку ввода сетки событий для публикации событий. Входящее событие привязывается к массиву EventGridEvents, а выходящее публикуется в IAsyncCollector типов EventGridEvent. Тип параметра определяет тип данных для входных данных в эту функцию.

Чем привязки отличаются в изолированных функциях процесса?

Как и функции библиотеки классов привязка определяется с помощью атрибута в параметрах, методах и возвращаемых типах.

Привязки в изолированном проекте .net отличаются тем, что не могут использовать классы привязки, такие как IAsyncCollector<T>. Также нельзя использовать типы, унаследованные от SDK, например DocumentClient. Вместо этого приходится полагаться на строки, массивы и POCO (Plain Old Class Objects).

Проиллюстрируем это примером. Создана функция, которая получает HTTP POST-запрос и передает документ на хранение в Cosmos DB.

Вот код функции:

using System;

using System.IO;

using System.Net;

using System.Threading.Tasks;

using Microsoft.Azure.Functions.Worker;

using Microsoft.Azure.Functions.Worker.Http;

using Microsoft.Extensions.Logging;

using Newtonsoft.Json;

namespace IsolatedBindings

{

public static class InsertTodo

{

[Function("InsertTodo")]

[CosmosDBOutput("%DatabaseName%", "%ContainerName%", ConnectionStringSetting = "CosmosDBConnectionString")]

public static async Task<object> Run([HttpTrigger(AuthorizationLevel.Anonymous, "post")] HttpRequestData req,

FunctionContext executionContext)

{

HttpResponseData response;

var logger = executionContext.GetLogger("InsertTodo");

logger.LogInformation("C# HTTP trigger function processed a request.");

try

{

var request = await new StreamReader(req.Body).ReadToEndAsync();

var todo = JsonConvert.DeserializeObject<TodoItem>(request);

todo.Id = Guid.NewGuid().ToString();

return todo;

}

catch (Exception ex)

{

logger.LogError($"Exception thrown: {ex.Message}");

response = req.CreateResponse(HttpStatusCode.InternalServerError);

}

return response;

}

Эта функция использует привязку для вывода Azure Cosmos DB. К методу функции, который определяет, как записывается POST-запрос в службе Cosmos DB, применяется атрибут привязки. Для того чтобы использовать привязку CosmosDBOutput, необходимо установить следующий пакет:

Microsoft.Azure.Functions.Worker.Extensions.CosmosDB

Поскольку функции, исполняемые в изолированному процессе, используют различные типы привязок важно использовать другой набор пакетов расширения привязки.

С полным списком можно ознакомиться по ссылке:

https://www.nuget.org/packages?q=Microsoft.Azure.Functions.Worker.Extensions

В функциях библиотек классов привязка была бы определена для вывода в атрибуте метода, где определили бы тип вывода и записали выводную функцию в это привязку таким образом.

В изолированных функциях значение, возвращаемое нашим методом - это значение, которое будет записано в привязку Cosmos DB Output. Таким образом, в функции создается POST-запрос, содержащий элемент Todo, который необходимо записать Cosmos DB и когда он будет возвращен из функции, то будет записан в Cosmos DB.

Проверим это! Используем Postman для создания следующего запроса:

После запуска функции должна быть получена локальная конечная точка для отправки POST-запроса, например так:

http://localhost:7071/api/InsertTodo

При создании POST-запроса на эту конечную точку получаем следующий ответ:

Зайдем в учетную запись Cosmos DB и проверим, что документ был успешно записан в:

Создание Serverless API с помощью Azure Cosmos DB

Fri, 24 Sep 2021 09:12:02 GMT

Azure Cosmos DB - глобально распределенная, многомодельная служба базы данных NoSQL, используемая для создания высокодоступных и масштабируемых приложений. Cosmos DB поддерживает приложения, использующие данные модели документов через SQL API and MongoDB API.

Azure Cosmos DB реализует проводной протокол для Mongo DB, разрешающий использовать привычные драйверы и инструменты, но с возможностью размещения данных в Azure Cosmos DB.

Стало возможным менять приложения для использования Azure Cosmos DB без внесения кардинальных изменений в базу исходного кода, пользоваться преимуществами Azure Cosmos DB, такими как распределение Turnkey и эластичная масштабируемость как в пропускной способности, так и в хранилище.

Настройка учетной записи с помощью MongoDB API

Начнем с создания учетной записи Cosmos DB. Войдите в Azure и нажмите " Create a resource". Найдите Azure Cosmos DB и нажмите "New".

На странице ‘Create Azure Cosmos DB Account’ укажите следующую информацию:

· Resource Group – группы ресурсов в Azure, представляющие собой логическую коллекцию ресурсов. Создайте новую или добавьте свою учетную запись в существующую.

· Account Name - уникальное в Azure имя учетной записи. API — Azure Cosmos DB - многомодельная база данных, но при создании учетной записи в Cosmos DB выбираем только один API на весь срок действия учетной записи.

· Location - то, где будет зарегистрирована учетная запись. В примере выбрана Восточная Австралия. Выбирайте удобный для себя.

· Capacity Mode - то, как будет обеспечиваться пропускная способность в учетной записи.

· Account Type - выберите производственную среду

· Version - версия протокола Mongo DB, который будет поддерживать учетная запись. Выбираем 3.6

· Availability Zones - отключите.

Нажмите Review+Create, затем Create для создания учетной записи Cosmos DB.

После настройки учетной записи появляется возможность создания базы данных и коллекции.

В учетной записи Cosmos DB зайдите в проводник данных и нажмите ‘New Collection’. Введите ‘BookstoreDB’ в качестве имени базы данных и Books - как название коллекции. Затем выберите ключ для разделения документов из коллекции по узлам.

Сегментирование в Mongo DB - метод распределения данных между несколькими машинами. Важно, этот сегмент поможет приложению масштабироваться как с точки зрения пропускной способности, так и с точки зрения хранения за счет горизонтального масштабирования.

Теперь созданы база данных, коллекция и учетная запись. Но для настройки нужна еще строка подключения. Нажмите Connection String и скопируйте значение PRIMARY CONNECTION STRING.

Создание Function Application

Выберите ‘Azure Functions’ в качестве шаблона для создания проекта (Убедитесь, что выбран язык C#).

Назовем проект ‘CosmosBooksApi’, сохраните проект в выбранном месте и нажмите создать.

Выберите Azure Functions v3 (.NET Core) в качестве среды выполнения кода и создайте пустой проект без триггеров.

Перед началом создания функций важно установить пакет MongoDB.Driver. Для это нажмите правой клавишей мыши на проект и выберите ‘Manage NuGet Packages’. В разделе Browse введите MongoDB.Driver и установите последнюю стабильную версию.

После установки создадим файл Startup.cs, который создаст экземпляр нашего MongoClient:

using CosmosBooksApi;

using CosmosBooksApi.Services;

using Microsoft.Azure.Functions.Extensions.DependencyInjection;

using Microsoft.Extensions.Configuration;

using Microsoft.Extensions.DependencyInjection;

using MongoDB.Driver;

using System.IO;

using System.Security.Authentication;

[assembly: FunctionsStartup(typeof(Startup))]

namespace CosmosBooksApi

{

public class Startup : FunctionsStartup

{

public override void Configure(IFunctionsHostBuilder builder)

{

var config = new ConfigurationBuilder()

.SetBasePath(Directory.GetCurrentDirectory())

.AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)

.AddEnvironmentVariables()

.Build();

builder.Services.AddSingleton<IConfiguration>(config);

MongoClientSettings settings = MongoClientSettings.FromUrl(new MongoUrl(config["ConnectionString"]));

settings.SslSettings = new SslSettings() { EnabledSslProtocols = SslProtocols.Tls12 };

builder.Services.AddSingleton((s) => new MongoClient(settings));

builder.Services.AddTransient<IBookService, BookService>();

}

Начиная со второй версии Azure Functions появилась поддержка для внедрения зависимостей, разрешающая создавать экземпляр MongoClient как Singleton. Таким образом можно совместно использовать MongoClient среди функций и избежать создания нового экземпляра для клиента каждый раз, когда хотим вызвать Функции.

Для регистрации наших сервисов добавим компоненты в экземпляр IFunctionsHostBuilder, который передается как метод настройки

Для использования этого метода добавим атрибут FunctionsStartup в сам класс загрузки.

Затем создадим новую конфигурацию типа IConfiguration. Все, что нужно - это выбрать конфигурацию для Function application из файла local.settings.json Затем добавить сервис IConfiguration как Singleton.

Теперь настроим MongoClient. Начинаем с настройки строки подключения путем передачи нашей PRIMARY CONNECTION STRING в качестве объекта MongoUrl() Сохраним это в нашем local.settings.json file.

{

"IsEncrypted": false,

"Values": {

"AzureWebJobsStorage": "UseDevelopmentStorage=true",

"FUNCTIONS_WORKER_RUNTIME": "dotnet",

"ConnectionString": "<PRIMARY_CONNECTION_STRING>",

"DatabaseName": "BookstoreDB",

"CollectionName": "Books"

}

Затем передаем ключ настройки в объект MongoUrl.Подключаем SSL, используя протокол Tls12 в SslSettings для MongoClientSettings. Это требование Azure Cosmos DB для подключения к учетной записи API MongoDB.После настройки MongoClientSettings, передаем их в объект MongoClient, который настроен как Singleton Service.Теперь создаем базовый класс для представления нашей модели Book. Напишем следующее:

using MongoDB.Bson;

using MongoDB.Bson.Serialization.Attributes;

namespace CosmosBooksApi.Models

{

public class Book

{

[BsonId]

[BsonRepresentation(BsonType.ObjectId)]

public string Id { get; set; }

[BsonElement("name")]

public string BookName { get; set; }

[BsonElement("price")]

public decimal Price { get; set; }

[BsonElement("category")]

public string Category { get; set; }

[BsonElement("author")]

public string Author { get; set; }

}

В этом классе есть свойства для Book id, имени, цены, категории, автора. ID отмечен BsonId как первичный ключ документа. Также аннотировали ID [BsonRepresentation(BsonType.ObjectId)] для передачи ID как строкового типа, а не ObjectId. Mongo будет обрабатывать преобразование строки в объект. Остальные свойства аннотированы с помощью [BsonElement()]. Это определит как свойства будут выглядеть в коллекции. Создадим службу, которая обрабатывает логику, работающую с учетной записью Cosmos DB. Дадим интерфейсу название IBookService.cs.

using CosmosBooksApi.Models;

using System.Collections.Generic;

using System.Threading.Tasks;

namespace CosmosBooksApi.Services

{

public interface IBookService

{

/// <summary>

/// Get all books from the Books collection

/// </summary>

/// <returns></returns>

Task<List<Book>> GetBooks();

/// <summary>

/// Get a book by its id from the Books collection

/// </summary>

/// <param name="id"></param>

/// <returns></returns>

Task<Book> GetBook(string id);

/// <summary>

/// Insert a book into the Books collection

/// </summary>

/// <param name="book"></param>

/// <returns></returns>

Task CreateBook(Book bookIn);

/// <summary>

/// Updates an existing book in the Books collection

/// </summary>

/// <param name="id"></param>

/// <param name="book"></param>

/// <returns></returns>

Task UpdateBook(string id, Book bookIn);

/// <summary>

/// Removes a book from the Books collection

/// </summary>

/// <param name="book"></param>

/// <returns></returns>

Task RemoveBook(Book bookIn);

/// <summary>

/// Removes a book with the specified id from the Books collection

/// </summary>

/// <param name="id"></param>

/// <returns></returns>

Task RemoveBookById(string id);

}

Это простой интерфейс CRUD, определяющий контракт, который должен быть реализован сервисами. Реализуем этот интерфейс:

using CosmosBooksApi.Models;

using Microsoft.Extensions.Configuration;

using MongoDB.Driver;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

namespace CosmosBooksApi.Services

{

public class BookService : IBookService

{

private readonly MongoClient _mongoClient;

private readonly IMongoDatabase _database;

private readonly IMongoCollection<Book> _books;

public BookService(

MongoClient mongoClient,

IConfiguration configuration)

{

_mongoClient = mongoClient;

_database = _mongoClient.GetDatabase(configuration["DatabaseName"]);

_books = _database.GetCollection<Book>(configuration["CollectionName"]);

}

public async Task CreateBook(Book bookIn)

{

await _books.InsertOneAsync(bookIn);

}

public async Task<Book> GetBook(string id)

{

var book = await _books.FindAsync(book => book.Id == id);

return book.FirstOrDefault();

}

public async Task<List<Book>> GetBooks()

{

var books = await _books.FindAsync(book => true);

return books.ToList();

}

public async Task RemoveBook(Book bookIn)

{

await _books.DeleteOneAsync(book => book.Id == bookIn.Id);

}

public async Task RemoveBookById(string id)

{

await _books.DeleteOneAsync(book => book.Id == id);

}

public async Task UpdateBook(string id, Book bookIn)

{

await _books.ReplaceOneAsync(book => book.Id == id, bookIn);

}

Введем зависимости в MongoClient и IConfiguration, затем создадим базу данных и коллекцию для выполнения операций с ними. Рассмотрим различные методы.InsertOneAsync - асинхронно вставляет документ в IMongoCollection. Передается документ, который хотим сохранить. В данном случае это объект Book. Также можем передать некоторые пользовательские параметры (InsertOneOptions) и CancellationToken.FindAsync - асинхронно находит документ, который соответствует фильтру. Используется лямбда-выражение для поиска книги с тем же ID, который указан в методе. Linq используется для возврата соответствующей книги.DeleteOneAsync - асинхронно удаляет документ, соответствующий выражению. Опять же, используется лямба-выражение для поиска книги, которую необходимо удалить. В этом методе возвращается только результат операции.ReplaceOneAsync - приводит к асинхронной замене документа.Итак, MongoClient создан и есть базовая служба CRUD, которая используется для взаимодействия с учетной записью Cosmos DB. Перейдем к созданию функций.В качестве примера создадим следующие функции:

CreateBook
DeleteBook
GetAllBooks
GetBookById
UpdateBook

Для создания новой функции щелкните правой клавишей мыши по файлу нашего решения и выберите ‘Add New Azure Function’. Появляется всплывающее окно. Выбираем Http Trigger, далее Anonymous в качестве уровня авторизации функции.Начнем с функции CreateBook:

using CosmosBooksApi.Models;

using CosmosBooksApi.Services;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

using Microsoft.Azure.WebJobs;

using Microsoft.Azure.WebJobs.Extensions.Http;

using Microsoft.Extensions.Logging;

using MongoDB.Bson;

using Newtonsoft.Json;

using System;

using System.IO;

using System.Threading.Tasks;

namespace CosmosBooksApi.Functions

{

public class CreateBook

{

private readonly ILogger<CreateBook> _logger;

private readonly IBookService _bookService;

public CreateBook(

ILogger<CreateBook> logger,

IBookService bookService)

{

_logger = logger;

_bookService = bookService;

}

[FunctionName(nameof(CreateBook))]

public async Task<IActionResult> Run(

[HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "Book")] HttpRequest req)

{

IActionResult result;

try

{

var incomingRequest = await new StreamReader(req.Body).ReadToEndAsync();

var bookRequest = JsonConvert.DeserializeObject<Book>(incomingRequest);

var book = new Book

{

Id = ObjectId.GenerateNewId().ToString(),

BookName = bookRequest.BookName,

Price = bookRequest.Price,

Category = bookRequest.Category,

Author = bookRequest.Author

};

await _bookService.CreateBook(book);

result = new StatusCodeResult(StatusCodes.Status201Created);

}

catch (Exception ex)

{

_logger.LogError($"Internal Server Error. Exception: {ex.Message}");

result = new StatusCodeResult(StatusCodes.Status500InternalServerError);

}

return result;

}

Здесь вводим IBookService и ILogger в функцию. Вызываем эту функцию, отправляя запрос POST на ‘/Book’. Берем входящий HttpRequest и выполняем десериализацию в объект Book. Затем вставляет книгу в коллекцию Books. Если все прошло успешно, то получим ответ 201 (Создан). Если нет, ответ 500.

Теперь рассмотрим функцию DeleteBook:

using CosmosBooksApi.Services;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

using Microsoft.Azure.WebJobs;

using Microsoft.Azure.WebJobs.Extensions.Http;

using Microsoft.Extensions.Logging;

using System;

using System.Threading.Tasks;

namespace CosmosBooksApi.Functions

{

public class DeleteBook

{

private readonly ILogger<DeleteBook> _logger;

private readonly IBookService _bookService;

public DeleteBook(

ILogger<DeleteBook> logger,

IBookService bookService)

{

_logger = logger;

_bookService = bookService;

}

[FunctionName(nameof(DeleteBook))]

public async Task<IActionResult> Run(

[HttpTrigger(AuthorizationLevel.Anonymous, "delete", Route = "Book/{id}")] HttpRequest req,

string id)

{

IActionResult result;

try

{

var bookToDelete = await _bookService.GetBook(id);

if (bookToDelete == null)

{

_logger.LogWarning($"Book with id: {id} doesn't exist.");

result = new StatusCodeResult(StatusCodes.Status404NotFound);

}

await _bookService.RemoveBook(bookToDelete);

result = new StatusCodeResult(StatusCodes.Status204NoContent);

}

catch (Exception ex)

{

_logger.LogError($"Internal Server Error. Exception thrown: {ex.Message}");

result = new StatusCodeResult(StatusCodes.Status500InternalServerError);

}

return result;

}

На этот раз передаем ID в нашу функцию (‘/Book/id’) для поиска книга, которую необходимо удалить из коллекции. Сначала ищем книгу, используя метод IBookService..GetBook(id). Если книга не существует, функция выдаст ответ 404 (не найдена).

Если книга найдена, передаем ее в метод RemoveBook(book) для удаления из коллекции в Cosmos DB. В случае успешного выполнения - ответ 204.

Код для функции GetAllBooks:

using CosmosBooksApi.Services;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

using Microsoft.Azure.WebJobs;

using Microsoft.Azure.WebJobs.Extensions.Http;

using Microsoft.Extensions.Logging;

using System;

using System.Threading.Tasks;

namespace CosmosBooksApi.Functions

{

public class GetAllBooks

{

private readonly ILogger<GetAllBooks> _logger;

private readonly IBookService _bookService;

public GetAllBooks(

ILogger<GetAllBooks> logger,

IBookService bookService)

{

_logger = logger;

_bookService = bookService;

}

[FunctionName(nameof(GetAllBooks))]

public async Task<IActionResult> Run(

[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "Books")] HttpRequest req)

{

IActionResult result;

try

{

var books = await _bookService.GetBooks();

if (books == null)

{

_logger.LogWarning("No books found!");

result = new StatusCodeResult(StatusCodes.Status404NotFound);

}

result = new OkObjectResult(books);

}

catch (Exception ex)

{

_logger.LogError($"Internal Server Error. Exception thrown: {ex.Message}");

result = new StatusCodeResult(StatusCodes.Status500InternalServerError);

}

return result;

}

В этой функции передается запрос GET на ‘/Books’. Эта функция вызовет метод .GetBooks() в IBookService для извлечения всех книг из коллекции. Если книг нет - ответ 404. Если книги есть, функция вернет их пользователю в виде массива.

Функция GetBookById схожа с GetAllBooks , но на этот раз передается ID книги, которую нужно вернуть:

using CosmosBooksApi.Services;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

using Microsoft.Azure.WebJobs;

using Microsoft.Azure.WebJobs.Extensions.Http;

using Microsoft.Extensions.Logging;

using System;

using System.Threading.Tasks;

namespace CosmosBooksApi.Functions

{

public class GetBookById

{

private readonly ILogger<GetBookById> _logger;

private readonly IBookService _bookService;

public GetBookById(

ILogger<GetBookById> logger,

IBookService bookService)

{

_logger = logger;

_bookService = bookService;

}

[FunctionName(nameof(GetBookById))]

public async Task<IActionResult> Run(

[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "Book/{id}")] HttpRequest req,

string id)

{

IActionResult result;

try

{

var book = await _bookService.GetBook(id);

if (book == null)

{

_logger.LogWarning($"Book with id: {id} doesn't exist.");

result = new StatusCodeResult(StatusCodes.Status404NotFound);

}

result = new OkObjectResult(book);

}

catch (Exception ex)

{

_logger.LogError($"Internal Server Error. Exception thrown: {ex.Message}");

result = new StatusCodeResult(StatusCodes.Status500InternalServerError);

}

return result;

}

Также передается ID на функцию UpdateBook. Сначала вызываем метод. GetBook(id) для поиска книги, которую хотим обновить. После нахождения книги читаем входящий запрос и десериализируем его в объект Book. Затем используем десериализованный запрос для обновления объекта Book и передаем этот объект в метод .UpdateBook() вместе с ID, который использовали для вызова функции.

using CosmosBooksApi.Models;

using CosmosBooksApi.Services;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

using Microsoft.Azure.WebJobs;

using Microsoft.Azure.WebJobs.Extensions.Http;

using Microsoft.Extensions.Logging;

using Newtonsoft.Json;

using System;

using System.IO;

using System.Threading.Tasks;

namespace CosmosBooksApi.Functions

{

public class UpdateBook

{

private readonly ILogger<UpdateBook> _logger;

private readonly IBookService _bookService;

public UpdateBook(

ILogger<UpdateBook> logger,

IBookService bookService)

{

_logger = logger;

_bookService = bookService;

}

[FunctionName(nameof(UpdateBook))]

public async Task<IActionResult> Run(

[HttpTrigger(AuthorizationLevel.Anonymous, "put", Route = "Book/{id}")] HttpRequest req,

string id)

{

IActionResult result;

try

{

var bookToUpdate = await _bookService.GetBook(id);

if (bookToUpdate == null)

{

_logger.LogWarning($"Book with id: {id} doesn't exist.");

result = new StatusCodeResult(StatusCodes.Status404NotFound);

}

var input = await new StreamReader(req.Body).ReadToEndAsync();

var updateBookRequest = JsonConvert.DeserializeObject<Book>(input);

Book updatedBook = new Book

{

Id = id,

BookName = updateBookRequest.BookName,

Author = updateBookRequest.Author,

Category = bookToUpdate.Category,

Price = updateBookRequest.Price

};

await _bookService.UpdateBook(id, updatedBook);

result = new StatusCodeResult(StatusCodes.Status202Accepted);

}

catch (Exception ex)

{

_logger.LogError($"Internal Server Error: {ex.Message}");

result = new StatusCodeResult(StatusCodes.Status500InternalServerError);

}

return result;

}

Проверка функции

После завершения кодирования функций следующие этапы - развертывание и тестирование. Нажмите F5 для локального запуска функции. Через пару секунд функции будут развернуты и появятся endpoints для функций.

Функции выполняются в локальном хосте. Используем Postman для тестирования endpoints.

Начнем с функции CreateBook. Скопируйте и вставьте крайнюю точку функции в Postman. Установите метод запроса POST и щелкните вкладку. Необходимо отправить запрос в качестве JSON payload, поэтому установите для него JSON и добавьте следующее:

{

"BookName" : "Computer Science: Distilled",

"Price": 11.99,

"Category": "Technology",

"Author": "Wladston Ferreira Filho"

}

Нажмите Send для отправки запроса. Получен ответ (201).

Чтобы убедиться, что документ добавлен в учетную запись, можно просмотреть документ в учетной записи Cosmos DB.

Вставьте еще пару книг прежде, чем двигаться дальше. Теперь попытаемся извлечь все книги из нашей коллекции, используя функцию GetAllBooks. Удалите JSON payload из тела и измените метод запроса на GET. Нажмите Send для создания запроса.

Должен быть получен подобный ответ:

Здесь книги коллекции, возвращенные в качестве массива JSON. Теперь протестируем функцию GetBookById. В ответ на функцию GetAllBooks, возьмите ID и добавьте его в качестве параметра в маршрут обработки запроса. Все, что здесь изменилось это то, что нужно найти конкретную книгу, используя ее ID.

Нажмите Send для создания запроса. У нас должен быть объект книга, возвращенный к нам:

Теперь удалим книгу из коллекции Cosmos DB. Измените метод запроса на DELETE в Postman и нажмите Send.

Должен быть получен следующий ответ:

Если проверить коллекцию в Azure Cosmos DB, увидим, что книги здесь больше нет.

Наконец, попробуем обновить книгу. Возьмем следующую книгу из коллекции:

{

"id": "603ae1b621786dd7fd92d5c0",

"bookName": "The Dark Net",

"price": 18.99,

"category": "Technology",

"author": "Jamie Bartlett"

}

Возьмем ID и используем его в качестве параметра в функции UpdateBook. Изменим метод на запрос PUT и добавим следующее в запрос:

{

"bookName": "The Dark Net v2",

"price": 11.99,

"author": "Jamie Bartlett"

}

Эта текстовая часть отправляется как JSON payload. Нажимаем Send для обновления документа книга.

Получаем следующий ответ.

Проверим успешность обновления документа в учетной записи Cosmos DB.

На этом примере удалось увидеть, что даже если приложения созданы с использованием MongoDb, Вы можете легко изменить его на Azure Cosmos DB, не внося серьезных изменений в базу исходного кода.

Миграция базы данных с сервера Microsoft SQL Server on-premises в Azure SQL database

Mon, 05 Jul 2021 08:28:10 GMT

Введение

В данном руководстве описан процесс миграции базы данных с сервера Microsoft SQL Server on-premises в Azure SQL database посредством экспорта Data-tier Application и последующего импорта базы Azure SQL database из bacpac-файла.

Перед началом процесса миграции следует обеспечить выполнение следующих условий:

Логин на сервере on-premises, с которого нужно перенести базу (под которым предполагается выполнять этот перенос) должен входить в роль сервера sysadmin.
Должны быть созданы учётная запись и подписка в Azure.

Сам процесс миграции состоит из следующих шагов:

Создание storage account и блоб-контейнера в нём в Azure.
Экспорт bacpac-файла базы данных с сервера Microsoft SQL Server on-premises в блоб-контейнер.
Создание инстанса SQL Server в Azure.

Импорт базы данных из bacpac-файла, сохраненного в блоб-контейнере в инстанс SQL Server в Azure

Создание storage account и блоб-контейнера в нём в Azure

Открываем в браузере portal.azure.com и после входа в свою учётную запись на домашней странице нажимаем “Create a resource”.
На открывшейся странице нажимаем “Storage account”.

На открывшейся странице “Create a storage account” указываем следующие значения:

Поле	Значение
Subscription	Подписка, в которой создаётся storage account.
Resource group	Существующая или новая группа в зависимости от предпочтений.
Storage account name	Имя создаваемого storage аккаунта. Должно быть уникальным среди всех storage аккаунтов в Azure, от 3 до 24 символов, только строчные буквы и цифры. На скриншоте ниже - frdsstorageacc.
Region	Регион в котором будет создан storage account. Рекомендуется использовать тот же регион, в котором будет создан Azure SQL server.
Performance	Standard или Premium (что по сути означает HDD или SSD для создаваемого storage account) в зависимости от потребностей и бюджета. На скриншоте выбрано значение по умолчанию Standard.
Redundancy	Куда будет реплицироваться storage account, для обеспечения high availability. Выбирается опция в зависимости от потребностей и бюджета. На скриншоте выбрано значение по умолчанию Geo-redundant storage (GRS).
Make read access to data available in the event of regional unavailability.	Оставляем значение по умолчанию.

Нажимаем “Review + create” и после валидации всех настроек ещё раз “Create”. Создание storage account может занять несколько минут.
После завершения создания нажимаем“Go to resource”.
В левой части страницы созданного storage account нажимаем “Containers”.
На открывшейся странице нажимаем “+ Container”.
Указываем желаемое имя контейнера, остальные настройки оставляем по умолчанию.

9. Нажимаем “Create” - контейнер будет создан и отображён на странице аккаунта.

На этом процесс создания storage account и настройки контейнера можно считать завершенным.

Экспорт bacpac-файла базы данных с сервера Microsoft SQL Server on-premises в блоб-контейнер

Открываем SSMS и подключаемся к on-premises SQL Server, на котором находится база для переноса.
Нажимаем на базу правой кнопкой мыши и в появившемся контекстном меню выбираем Tasks -> Export Data-tier.
В появившемся окне Introduction нажимаем “Next”.
На вкладке Export Settings выбираем “Save to Microsoft Azure” и нажимаем кнопку “Connect...” для подключения к storage account.
В появившейся форме для аутентификации в Azure вводим данные своей учётной записи.
После аутентификации в появившемся окне выбираем подписку, storage account и блоб контейнер, куда будет сохранён bacpac-файл и нажимаем “ОК”.

7. Убеждаемся, что в окне Export Settings указаны правильные значения и нажимаем Next, а затем Finish.

8. Процесс экспорта отображается в окне “Progress”.

9. После завершения экспорта закрываем окно. Можно открыть контейнер на портале Azure и убедиться, что bacpac-файл был успешно

скопирован.

На этом экспорт bacpac-файла в блоб контейнер можно считать завершённым.

Создание инстанса SQL Server в Azure

Открываем в браузере portal.azure.com, переходим на домашнюю страницу и нажимаем “Create a resource”.
В строке поиска набираем “SQL Server” и нажимаем ввод.
В результатах поиска находим ресурс “Azure SQL” и нажимаем на него.
На открывшейся странице нажимаем “Create”.

5. На открывшейся странице в разделе “How do you plan to use the service?” доступно три опции - “SQL databases”, “SQL managed instances” и “SQL virtual machines”. В данном руководстве рассмотрен процесс создания SQL databases. Нажав на “Show details” на панели “SQL databases”, можно увидеть описание различных типов ресурсов для этой опции - “Single database”, “Elastic pool” и “Database server”. Выбор типа ресурса зависит от потребностей, для данного примера выбираем “Database server” и нажимаем “Create”.

6. На открывшейся странице указываем следующие значения

Поле	Значение
Subscription	Подписка, в которой создаётся сервер.
Resource group	Существующая или новая группа в зависимости от предпочтений.
Server name	Имя создаваемого сервера. Должно быть уникальным среди всех серверов в Azure, не должно быть зарезервированным словом. Должно содержать только строчные буквы, цифры и “-”, но не может начинаться с “-”. Длина - не более 63 символов. На скриншоте ниже - forrardssql.
Region	Регион в котором будет создан сервер.
Server admin login	Логин для админа.
Password	Пароль для админского логина.
Confirm password	Ещё раз пароль.

7. Нажимаем “Review + create”, а затем ещё раз “Create”. Создание сервера может занять несколько минут.

На этом создание инстанса SQL Server в Azure можно считать завершённым.

Импорт базы данных из bacpac-файла, сохраненного в блоб-контейнере, в инстанс SQL Server в Azure

1. После завершения создания инстанса SQL Server в Azure, на открывшейся странице нажимаем “Go to resource”

2. На открывшейся странице нажимаем “Import database”.

3. На открывшейся странице нужно указать параметры импортируемой базы данных. Для выбора bacpac-файла, созданного ранее, нажимаем “Select backup”.

4. Далее нужно выбрать storage account и блоб-контейнер в нём, куда был экспортирован bacpac-файл, а затем выбрать этот файл и нажать “Select”.

5. Выбранный файл отобразится в окне настройки параметров импорта. Следующим шагом нужно выбрать ресурсы, используемые базой данных. Для этого нажимаем “Configure database”.

6. Ресурсы выбираются в зависимости от планируемой нагрузки и бюджета, для данного примера была выбрана минимальная конфигурация. После выбора конфигурации нажимаем “Apply”.

7. Выбранная конфигурация отобразится в окне настройки параметров импорта.

8. Последним шагом указываем название базы данных, collation, а также логин и пароль для входа на сервер (те значения, которые были заданы на этапе создания сервера). После указания всех параметров нажимаем “ОК”. Импорт базы данных займёт какое-то время в зависимости от количества данных. Следует иметь в виду, что панель с уведомлениями, отображающая прогресс импорта базы через какое-то время может зависнуть и показывать, что импорт продолжается тогда, когда по факту он уже завершился. Для большей надёжности следует проверять состояние базы, открыв её в “All resources”.

На этом процесс миграции базы данных с сервера Microsoft SQL Server on-premises в Azure SQL database можно считать завершённым.

Полезные ссылки

Quickstart: Import a BACPAC file to a database in Azure SQL Database or Azure SQL Managed Instance

https://docs.microsoft.com/en-us/azure/azure-sql/database/database-import?tabs=azure-powershell

Миграция базы данных с сервера Microsoft SQL Server on-premises в Azure SQL managed instance посредством backup/restore

Tue, 15 Jun 2021 06:51:29 GMT

В данном руководстве описан процесс миграции базы данных с сервера Microsoft SQL Server on-premises в Azure SQL managed instance.

Перед началом процесса миграции следует обеспечить выполнение следующих необходимых условий:

Логин на сервере on-premises, с которого нужно перенести базу (под которым предполагается выполнять этот перенос) должен входить в роль сервера sysadmin.

Должна быть создана подписка в Azure.

Должен быть создан ресурс Azure SQL managed instance в Azure.

В Azure SQL managed instance также должен быть создан логин, входящий в роль сервера sysadmin.

Сам процесс миграции состоит из следующих шагов:

- Создание в Azure ресурса storage account, в котором будет размещён бэкап базы данных.

- Бэкап базы данных с сервера on-premises в blob контейнер в Azure storage account.

- Рестор базы данных из blob контейнера в Azure storage account в Azure SQL managed instance.

Создание в Azure ресурса storage account, в котором будет размещён бэкап базы данных

Открывает в браузере portal.azure.com и входим в свою учётную запись.
Нажимаем кнопку “Create a resource” в верхней части страницы портала.

3. В открывшейся странице выбираем “Storage account”.

4. На открывшейся странице “Create a storage account” указываем следующие значения.

Поле	Значение
Subscription	Подписка, в которой создаётся storage account.
Resource group	Существующая или новая группа в зависимости от предпочтений.
Storage account name	Имя создаваемого storage аккаунта. Должно быть уникальным среди всех storage аккаунтов в Azure, от 3 до 24 символов, только строчные буквы и цифры. На скриншоте ниже - frdsstorageacc.
Region	Регион в котором будет создан storage account. Рекомендуется использовать тот же регион, в котором создан Azure SQL managed instance.
Performance	Standard или Premium (что по сути означает HDD или SSD для создаваемого storage account) в зависимости от потребностей и бюджета. На скриншоте выбрано значение по умолчанию Standard.
Redundancy	Куда будет реплицироваться storage account, для обеспечения high availability. Выбирается опция в зависимости от потребностей и бюджета. На скриншоте выбрано значение по умолчанию Geo-redundant storage (GRS).
Make read access to data available in the event of regional unavailability.	Оставляем значение по умолчанию.

5. Нажимаем “Review + create” и после валидации всех настроек ещё раз “Create”. Создание storage account может занять пару минут.

6. После завершения создания жмём “Go to resource”.

7. В левой части страницы созданного storage account нажимаем “Containers”.

8. На открывшейся странице нажимаем “+ Container”.

9. Указываем желаемое имя контейнера, остальные настройки оставляем по умолчанию.

10. Нажимаем “Create” - контейнер будет создан и отображён на странице аккаунта.

На этом процесс создания storage account и настройки контейнера можно считать завершённым. Страницу аккаунта в браузере следует оставить открытой, при бэкапе базы данных она потребуется для получения доступа к контейнеру.

Бэкап базы данных с сервера on-premises в blob контейнер в Azure storage account

Открываем SSMS и подключаемся к серверу on-premises под логином, входящим в роль сервера sysadmin.
Открываем окно для выполнения запросов.
Сначала нужно создать credential, под которым SSMS будет выполнять бэкап базы данных в Azure storage account. Для создания потребуется Access key созданного storage account. Возвращаемся в браузер с открытой страницей созданного аккаунта и нажимаем “Access keys”.

4. В открывшемся окне нажимаем “Show keys”.

Одно из значений Key для key1 или key2 нужно будет использовать на следующем шаге для создания credential.

5. В общем случае запрос для этого выглядит следующим образом

create credential [AzureStorageBackups] with

identity = '<storage account name>'

, secret = '<storage account key from portal (Access key)>';

Здесь <storage account name> нужно заменить на имя созданного storage account - frdsstorageacc, а <storage account key from portal (Access key)> - на одно из значений Key из предыдущего шага.

create credential [AzureStorageBackups] with

identity = 'frdsstorageacc'

, secret = 'sidxe6IRr9lJ4i4HaTnlxQYs2xfw5JNhED1nkMqVYvDtElm00K1LY3QldryLjluhgzKHVXH7bvLVUMM2Oy/uSA==';

6. Нажимаем F5 - будет создан credential.

7. Далее нужно получить URL контейнера, который был создан последним шагом при создании storage account в Azure. Переходим в браузер и в левой части страницы аккаунта нажимаем “Containers”.

8. Находим созданный контейнер (на скриншоте - backups) и кликаем по нему правой кнопкой мыши, а затем нажимаем к контекстном меню “Container properties”.

9. На появившейся странице видим URL с адресом контейнера.

10. В рамках данного руководства не рассматриваются различные опции, которые могут быть использованы при бэкапе баз данных, запрос написан в простейшем виде для демонстрационных целей. В общем виде он выглядит так.

backup database [<database name>]

to url = N'<container address>/<backup_file_name>'

with credential = '<credential>';

Здесь вместо <database name> указывается имя базы данных, вместо <container address> - URL контейнера из предыдущего шага, вместо <backup_file_name> - имя файла бэкапа и вместо <credential> - credential, созданный на шаге 6.

backup database [DataWarehouse]

to url = N'https://frdsstorageacc.blob.core.windows.net/backups/DataWarehouse_backup_20210525.bak'

with credential = 'AzureStorageBackups';

11. Нажимаем F5 - бэкап будет создан в контейнере внутри Azure storage account.

12. Вернувшись в браузер и открыв страницу контейнера, можно убедиться, что он содержит page blob с указанным на предыдущем шаге именем.

На этом процесс создания бэкапа можно считать завершённым. Страницу storage account в браузере следует оставить открытой, т.к. она понадобится на следующем шаге.

Рестор базы данных из blob контейнера в Azure storage account в Azure SQL managed instance

В SSMS подключаемся к Azure SQL managed instance под логином, входящим в роль сервера sysadmin.
Открываем окно для выполнения запросов.
Перед выполнением рестора нужно создать credential, под которым SSMS будет обращаться к Azure storage account. Credential, создаваемый на этом шаге отличается от того, который создавался для бэкапа базы данных. Возвращаемся на страницу контейнера в браузере и нажимаем “Shared access signature”.

4. На открывшейся странице можно оставить все опции по умолчанию и нажать “Generate SAS token and URL”.

5. На появившейся странице видим Blob SAS token.

6. Запрос для создания credential выглядит так.

create credential [<container address>] with

identity = 'SHARED ACCESS SIGNATURE'

, secret = '<SAS token>';

Здесь вместо <container address> нужно указать URL контейнера, тот же самый, который использовался при бэкапе, а вместо <SAS token> - значение Blob SAS token из предыдущего шага.

create credential [https://frdsstorageacc.blob.core.windows.net/backups] with

identity = 'SHARED ACCESS SIGNATURE'

, secret = 'sp=r&st=2021-05-25T12:11:13Z&se=2021-05-25T20:11:13Z&spr=https&sv=2020-02-10&sr=c&sig=9k57zcE2nzO666LPgIee%2Bx%2F%2Ba4lAj%2FbWbb%2FdX81fq04%3D';

7. Нажимаем F5 - будет создан credential.

8. Запрос для рестора базы данных:

restore database [DataWarehouse]

from url = N'<container address>/<backup_file_name>';

Здесь вместо <container address> нужно указать URL контейнера, а вместо вместо <backup_file_name> - имя файла бэкапа. Полный URL должен получиться точно таким же, какой использовался для бэкапа базы данных на сервере on-premises.

restore database [DataWarehouse]

from url = N'https://frdsstorageacc.blob.core.windows.net/backups/DataWarehouse_backup_20210525.bak';

9. Нажимаем F5 - через какое-то время база данных будет восстановлена.

На этом процесс миграции базы данных с сервера Microsoft SQL Server on-premises в Azure SQL managed instance можно считать завершённым.

Полезные ссылки

Backup database to Azure Blob Storage:

https://dallasdbas.com/sql-backups-azure-storage/

Restore database to Azure SQL Managed Instance from Azure Blob Storage:

https://docs.microsoft.com/en-us/azure/azure-sql/managed-instance/restore-sample-database-quickstart

Путешествие из локального в облако. Эпизод 2

Mon, 31 May 2021 13:28:11 GMT

Вы знаете, на что похожа миграция? На переезд. Я дважды переезжал. Упаковка, переупаковка, сортировка отнимают много времени. Небольшие коробки я перевозил на машине, но крупногабаритные вещи с помощью компании-перевозчика. Главная проблема переезда, так же как и миграции приложения заключается во времени и усилиях, затраченных на то, чтобы собрать, разобрать и вернуться к нормальной жизни.

А что, если бы была возможность отключить электричество, газ, воду и переехать на грузовичке на новое место, где, подключившись к службам жизнеобеспечения, продолжить жить? В подобном сценарии переезда не рассматривается процесс разбора или выбрасывания вещей. Мы отключаемся и подключаемся к источникам энергии и возвращаемся к прежнему образу жизни. И если для домашнего переезда это не совсем разумно, то для хостинговой среды приложения - вполне. Лучший путь миграции в облако - наименее ухабистая дорога.

Что такое lift and shift?

Lift and shift - стратегия миграции, которая выбирает путь наименьшего сопротивления, позволяя повторно размещать существующую рабочую нагрузку без модификаций. Как и при переезде, собирается все, что есть в дата-центре и перемещается это в облако. Но в отличие от переезда на новое местожительства, здесь не снимаются стойки и не вытаскиваются серверы.

Миграция lift and shift перемещает существующий сервер с текущего хоста в облачный с использованием инструментов для репликации того, что запущено на локальном решении. Это означает, что наша база данных SQL, IIS конфигурация, параметры реестра и конфигурация ОС - части нового развертывания на Azure без необходимости переписывания части приложения для PaS. В этом случае происходит перемещение на виртуальные машины Azure и сокращается время работы и усилий.

Ограничения

Миграция требует принятия ряда решений после выбора стратегии.

Зачем нужна миграция? – один из популярнейших вопросов. Главная причина – меньшая зона ответственности. Управление сетями, rack - конфигурации, системы резервного копирования, устройства балансировки нагрузки и другие части инфраструктуры подвергают дополнительному риску. Приходится быть экспертами во всем оборудовании, понимать как части взаимосвязаны между собой. Это сложно сделать только с помощью процесса разработки ПО и документации. Позвольте Azure обрабатывать эти вещи, в то время как Вы работаете над приложением. Иногда приходится сталкиваться с таким возражением:" Разве в облаке не дороже?" Дороже может быть только в случае, если во внимание не принимаются ресурсы, создаваемые в облаке. Выяснение того, что нужно, сколько и когда поможет лучше определить расходы и принести максимальную ценность. Кто будет осуществлять lift and shift? Кто будет следить за каждым шагом процесса миграции? Кто обновляет DNS? Это только несколько вопросов, которы важно проработать команде.

Azure Migrate

Azure Migrate - набор инструментов в Azure, который помогает в процессе lift and shift, предоставляет возможность обнаружить и определить, как выглядит текущее развертывание приложения. Используйте центральный репозиторий для перемещения таких элементов как резервные копии сервера и баз данных.

Azure Migrate оценивает и подготавливает серверы, веб-приложения, виртуальные рабочие столы и даже большие неструктурированные данные.

Azure Migrate помогает выполнить оценку на существующем развертывании для определения готовности к облачной миграции. Изучите существующие VMWare, Hyper-V, Xen, или даже серверы другой облачной хостинговой компании. Ключевые части оценки включают определение места миграции, размер виртуальных машин, использование и производительность серверов. После завершения Azure Migrate составляет рейтинг успешности миграции. Станет понятно, готовы ли Вы перейти в облако ДО того, как выполните этот процесс.

После определения того, что нужно, можно реплицировать серверы с использованием Azure Migrate, установленным на виртуализированный сервер Windows. Программно-аппаратный комплекс разворачивается на решениях VMware или Hyper-V, с использованием шаблонов OVA или VHD. Программно-аппаратный комплекс будет координировать взаимодействие, безопасность и процесс миграции данных для приложений.

После завершения репликации сервера необходимо время, подходящее для завершения миграции наилучшим образом, чтобы перейти на хост в Azure. Произведите некоторые финальные изменения в DNS или расскажите команде о начале использования нового расположения при входе в определенные приложения. Это продолжает процесс коммуникации, упомянутый ранее.

Информация, приведенная здесь, общая. Лучший способ начать изучать как выглядит миграция на практике - обучающий модуль от Microsoft “Design your migration to Azure”. Вместе с модулем идет много полезной информации на сайте Microsoft Docs. В случае, если что-то пойдет не так, всегда поможет служба поддержки Azure.

Требования к облачной миграции

Mon, 31 May 2021 13:28:07 GMT

Пандемия COVID-19 вынудила компании быстро менять приоритеты, чтобы оставаться на плаву. Как результат, ожидается, что до 85% предприятий перейдут в облако к 2025 г. Однако, сбор и миграция массивов данных в облако усложняет обеспечение целостности. Проблемы миграции решаются, опираясь на понятия целостности, безопасности и суверенитета. Хотя это и первоначально вызовет затруднения, однако в будущем приведет к оптимальным бизнес-решениям.

Трудности миграции данных в облако.

При перемещении данных в облако количество подключений к источникам и местам хранения увеличивается. По мере роста объемов данных возникают проблемы с поддержкой, связанные с согласованностью, точностью, доступностью и качеством. Таким образом, создание программы Data Governance требует дополнительных мер.

Сбор данных в единый источник до миграции в облако гарантирует, что члены команды работают с одной и той же информацией. Помимо объединения данных, инструменты сбора и интеграции, использующие машинное обучение и ИИ, помогут в сортировке поступающих данных. Ведение бизнеса в облаке способно спровоцировать новые расходы, которые при правильном подходе команды Data Management легко нивелируются.

Первый шаг - это проактивный подход к безопасности, которая достигается путем проведения полной инвентаризации, категоризации и классификации данных. Пренебрежение этим шагом гарантирует получение неоптимального результата в таких функциях, как соблюдение требований, управление рисками, оптимизация ценности информации и операционная эффективность. Воспользуйтесь комитетом Data Governance и инструментами классификации контента для категоризации дальнейших данных, которые поддерживают конкретные бизнес-единицы. Этот процесс помогает увеличить осведомленность о данных и повысить точность. Последний шаг - установление правил и процедур для укрепления и поддержки Data Governance в компании.

Целостность данных

Целостность данных - больше, чем инструмент. Поддержка данных в режиме реального времени требует отдельной команды и стратегии. Отдельное подразделение Data Management во главе с директором по обработке и анализу данных способствует правильному использованию данных. Перемещение данных в облако повысило необходимость наличия таких позиций как главный директор по обработке и анализу данных (CDO), руководитель службы защиты информации (CPO), руководитель по информационной безопасности для совместной работы над Data Governance.

Data Governance - точка пересечения сфер.

Безопасность данных

Наличие правильных инструментов и выделенной команды Data Governance повышает возможность компании в получение выгоды из данных. У нарушения требований соответствия двойной эффект: денежные штрафа и потеря доверия клиентов.

Безопасность данных - важная часть Data Governance. Защита данных в облаке отличается от on-premise новыми потоками, большей поверхностью атаки и повышенной сложностью конвейера. Данными в облаке легче обмениваться и получать к ним доступ. Информация из одного отдела может быть быстро отправлена в другой. К сожалению, такая доступность приводит к тому, что конфиденциальные данные оказываются не в том месте или не в тех руках.

Конфиденциальность и безопасность - элементы в обеспечении работоспособности и целостности данных, особенно в облаке. Для сохранения данных без ошибок и защиты от нарушения требуется отдельная команда. Команда, сосредоточенная на конфиденциальности и безопасности, может внедрить средства контроля безопасности, которые автоматизируют удаление или анонимизацию конфиденциальной информации и помогают избежать штрафов и потери репутации.

Суверенитет данных

В процессе переноса рабочих нагрузок в облако, упускается проблема суверенитета. Суверенитет данных - концепция, согласно которой данные подчиняются законам и структурам управления страны, в которой собираются.

Использование гибридного облачного подхода решает проблемы, связанные с суверенитетом данных. Организации с частными локальными средами преодолевают эти трудности без потери преимуществ, предоставляемых публичным облаком. Гибридные облака дают возможность выбирать данные для развертывания во внешнем облаке и данные для хранения в локальной среде.

Запомните: стратегия данных - это бизнес-стратегия. Инвестирование в правильные инструменты и опытную команду окупит вложенные инвестиции. По мере роста надежных корпоративных хранилищ, растут и доходы

Миграция кода с использованием автоматизации DevOps

Mon, 31 May 2021 13:28:01 GMT

Миграция из одной системы управления кодом в другую - нетривиальная задача. Командам важно поддерживать историю кода, структуру ветвей, разрешения и интеграции. Рассмотрим случай миграции с Bitbucket в GitHub крупной медицинской компании.

Обнаружив, что команды разработчиков использовали несколько систем управления исходным кодом, что приводило к увеличению затрат на поддержание задвоенных операций и стоимости лицензий, компания выбрала GitHub в качестве единой платформы для управления исходным кодом. Корпоративный продукт GitHub предлагает ряд преимуществ, включая интеграцию инструментов, понятный интерфейс для управления проектами и командами и уведомление о событиях, опцию для облачного или локального развертывания платформы управления исходным кодом.

Миграция нескольких тысяч репозиториев - серьезная проблема. От команды DevOps требуется соблюдение сроков продления лицензии. Во избежание дополнительных затрат, командам требуется перенести базу кода и связанные метаданные. В подходе, описанном ниже, используются следующие инструменты CloudBees Jenkins™ , Red Hat Ansible™ playbooks и скрипты Python.

Подход

Рис 1 демонстрирует, что миграция включает создание процесса миграции Jenkins для определения исходного проекта Bitbucket, целевой проект GitHub, информация о принадлежности команды, информация о репозитории, дополнительные требования для интеграции. Эта информация сохраняется в новом файле, добавленном в корень исходного дерева (‘app-info.yml’). Такой подход упрощает будущую автоматизацию интеграции и обеспечивает понятный способ отслеживания метаданных приложения в базе.

Рис 1 Процесс автоматизации миграции в Github

В автоматизации миграции прорабатываются факторы, включая обеспечение целевого проекта GitHub соответствующими разрешениями видимости, использование стандартов наименования проектов, интеграция с существующей или будущей автоматизацией сканирования безопасности, применение правил защиты, определенные организацией и поддержка автоматизации необходимых конвейеров CI/CD.

Трансфер кода

И хотя технически клонирование кода в новый репозиторий - элементарный вариант, но требует значительных ручных изменений в нескольких ключевых файлах автоматизации, находящихся в корне структуры папок проекта. К сожалению, принимая во внимание, что каждая команда разработчиков использует определенную версию библиотеки, этот шаг выполняется вручную, а не автоматическим.

Правила защиты

Организация установила набор правил управления версиями деревьев. Например, политика требует, чтобы запрос был одобрен хотя бы одним проверяющим до того, как код объединится для ветвей ‘master’, ‘release’, и ‘develop’ в репозитории. Эти правила закодированы в скриптах миграции python и извлекаются из Ansible playbook во время создания проекта GitHub.

Автоматизированные изменения конвейера CI/CD

Для поддержки существующих конвейеров CI/CD переносимые базы кода требовали обновления файла конфигурации конвейера. Сюда входили ссылки на конфигурацию для автоматического обновления Jira, автоматическое сканирование безопасности, интеграции с библиотекой package control. Эти изменения были записаны в скриптах python и извлечены из Ansible playbook во время миграции кода в GitHub.

Управление ключами доступа и учетными записями

Автоматизированные процессы CI/CD требуют использования учетных записей и общедоступного секретного ключа для правильного функционирования. В процессе миграции важно сохранить эти ключи доступа для предотвращения неправильного использования журналов, уведомлений или других небезопасных отчетов. Команда миграции использовала функцию Ansible vault и скрипты Groovy для обновления встроенной системы управления учетными записями Jenkins, чтобы гарантировать безопасную передачу ключей проекта/учетных записей во вновь созданные связанные джобы GitHub в процессе миграции.

GitHub Pre-Migration Setup

Интеграция GitHub Jenkins построена как отдельная задача для создания "команды" GitHub. Сюда входят конфигурация команды с собственным именем, административные пользователи и соответствие в папке сборки Jenkins. Для каждого репозитория также установлен Jenkins “web-hook” для гарантии того, что для каждого запуска конвейера CI/CD используется соответствующий мастер Jenkins.

Интеграция автоматизированного тестирования

Как часть контроля качества кода сканирование кода привязано к определенному репозиторию и подразумевается как часть рабочего процесса Jenkins CI/CD. Результаты сканирования отображаются в отдельной вкладке GitHub. Таким образом, созданный проект может напрямую сообщать разработчикам результаты автоматизированного анализа качества кода.

Результаты

Команде поддержки DevOps было необходимо уложиться в 4 мес для завершения полной миграции с Bitbucket to GitHub и избежать расходов на продление лицензии. Принимая во внимание масштаб проблемы, единственное подходящее решение - автоматизация большей части миграции. Использование комбинированного инструмента, состоящего из скриптов Jenkins, Ansible playbooks и сценариев Python, позволило команде DevOps успешно завершить процесс миграции и модификации всех баз кода за несколько недель до дедлайна. Как результат, все команды активны в GitHub, а репозитории Bitbucket заархивированы.

Миграция из облака в облако: когда делать, а когда забыть.

Fri, 30 Apr 2021 05:39:32 GMT

Миграция данных от одного облачного провайдера к другому - не такая простая задача. Когда речь идет о гигабайтах, терабайтах или петабайтах данных, миграция становится долгой и дорогостоящей процедурой. Несмотря на это, бывают ситуации, когда это стоит усилий и в некоторых ситуациях становится единственным способом двигаться вперед.

Зачем же рассматривать миграцию из облака в облако?

Необходимость модернизации операций, следующая за слиянием или поглощением, часто приводит бизнес-лидеров к решению о миграции. Хотя это и может показаться рациональным шагом, возможно, затраты и сбои перевесят любые преимущества. Важно полностью понимать происходящее, а затем оценивать потенциальные последствия перед принятием этого шага. Действительно ли Вам нужен полный переход из одного облака в другое? Или есть ли альтернативные подходы, которые помогли бы достичь желаемого результата другим способом?

В некоторых ситуациях логика подобной миграции более понятна. Это может быть важно для удовлетворения критических бизнес-требований, связанных с нахождением данных или правилами суверенитета данных.

Что осложняет миграцию из облака в облако?

Это не просто перенос данных из одной облачной среды в другую. Существует техническая часть, которую необходимо рассмотреть заранее, т.к. различия между ресурсами двух платформ могут потребовать новых решений.

Возьмем балансировщики нагрузки. В AWS они обрабатываются с помощью процедуры завершения SSL, в то время как в Azure требуется Azure Application Gateway. Это два совершенно разных зверя. Иногда кажется, что системы похожи в оркестровке контейнеров, например, Azure Kubernetes Service (AKS) and Amazon Elastic Kubernetes Service (EKS) , но они могут создавать технические трудности. В AWS управление идентификацией и доступом (IAM) в основном используется для контроля доступа, но в Azure этот момент будет покрываться с помощью Azure Active Directory (Azure AD). Любому приложению, мигрирующему от одного облачного провайдера к другому, необходима адаптация для поддержки метода, используемого конечной средой.

Конечное решение может выглядеть и работать одинаково, независимо от того, где оно расположено. Однако, для корректной работы в новой среде требуются изменения и компромисс. Разработчики и инженеры также должны быть готовы работать с новыми ресурсами.

Как решить, стоит ли это усилий?

Лица, принимающие решения, должны определить, превышают ли преимущества подобной миграции риски.

Ключевой фактор - влияние на команду. Подумайте, какие наборы знаний уже есть, а также о последствиях обучения и потенциальной утечки персонала.

Зрелость существующей деятельности в облаке также имеет значение. Если был достигнут прогресс в модернизации приложений и внедрении подходов DevOps, таких, как Ci/CD, это усложнит работу. Любая инфраструктура как код (IaC) или конфигурация как код (CaC) должны быть переписаны для новой среды.

Итак, Вы решили пойти на это. Что теперь?

К процессу миграции из облака в облако должен быть такой же подход, как и к любой другой миграции. Важно понимать целевые данные, высокоуровневый процесс миграции и как это будет синхронизировано. Потратьте время на изучение того, как методы автоматизации DevOps могут ускорить процесс миграции. Обратите внимание на мультиоблачные инструменты, особенно, если у команды есть опыт работы с ними.

Наверняка наступит период двойных облачных операций, когда используются новая и старая среды. Необходимо обеспечить наличие соответствующих инструментов и навыков для управления этой критической фазой. Необходим системный подход к обучению для подготовки команды к работе в новой облачной среде.

Наконец, не забывайте, что фаза двойного облака приведет к увеличению затрат.

Если Вы решили забыть об этом. Какие альтернативы?

В большинстве случаев, альтернативные подходы помогают в достижении желаемого результата без затрат и потрясений, связанных с миграцией из облака в облако.

Если оптимизация затрат стала толчком к рассмотрению этого шага, то существуют различные варианты, которые можно изучить. Выполнение ревью с фокусом на стоимости может помочь в определении возможностей для экономии затрат на текущей платформе. Большинство облачных поставщиков предлагают корпоративные соглашения, которые помогут обеспечить дальнейшую экономию средств, особенно в отношении устаревшего ПО. Внедрение практик DevOps и реконструкция для повышения производительности в существующих облачных средах, также могут преодолеть или компенсировать некоторые сложности.

3 главные ошибки мультиоблачной архитектуры

Fri, 30 Apr 2021 05:36:44 GMT

Оптимизация мультиоблачной архитектуры - это возможность настроить технологию для совершенствования архитектуры под бизнес-требования, а также для минимизации затрат. От каждого доллара, потраченного на облачную технологию, Вы хотите получать максимум отдачи для бизнеса.

Правда заключается в том, что лишь некоторые облачные архитектуры оптимизированы полностью. Сложность состоит в том, что об оптимизации архитектуры нужно подумать до развертывания и введению в эксплуатацию. Потом будет поздно.

Итак, рассмотрим причины, по которым мультиоблачная архитектура не может быть полностью оптимизирована.

1. Внедрение слишком большого числа технологий. Мультиоблачные архитекторы и команды разработчиков часто добавляют как можно больше технологий для всех типов требований, которые могут возникнуть. Вам может понадобиться только одна технология, но используете три; можете работать с одним ресурсом хранения, но у Вас их семь. В итоге, это дополнительные затраты и никакой дополнительной ценности для бизнеса.

Это сложная для разрешения проблема, потому что большинство архитекторов пытаются строить на будущее, которое еще не наступило. Они выбирают базы данных со встроенной технологией зеркального отображения, потому что могут полностью перейти на распределенные базы данных, хотя перспектива этого может быть отдаленной. Таким образом, количество типов баз данных увеличивается с 2х до 4х без веской на то причины. Имейте в виду, чтобы приблизиться к оптимизированному состоянию, необходимо строить для "минимального срока службы".

2. Не строить под конкретные требования. Детальные требования понятны, потому что изначально определяют, какой будет мультиоблачная архитектура, очерчивают схемы проблем, которые архитектура должна решать. Тем не менее до сих пор существует большое количество мультиоблачных проектов, которые проектируются и строятся под общие требования.

Требования определяют минимальный срок службы мультиоблачной архитектуры, а не наоборот.

3. Отсутствие гибкости. Архитекторы, занятые созданием мультиоблаков, даже если они близки к полной оптимизации, часто игнорируют гибкость при проектировании. В данном случае, гибкость означает понимание, что часть архитектуры должна легко адаптироваться под изменения, которые могут появиться в будущем.

Обязательно поместите волатильность в домен. Например, Вы ищете возможность избежать полной переделки базы данных или приложения вокруг простых изменений. Скажем, Вы используете виртуализацию данных между базами данных и приложениями, позволяющей изменять виртуальную схему так часто, как требуется для использования инструмента отображения без дорогостоящих изменений и рисков для физической базы данных в мультиоблаке. Это отличается от развертывания большинства технологий, т.к. изменение (включая степень и частоту) - само по себе требование.

Архитектура остается больше искусством, чем наукой. Понимание передовых практик принесет гораздо больше пользы бизнесу. В этом и состоит цель.

Путешествие из локального в облако: начало (Эпизод 1)

Fri, 30 Apr 2021 05:33:15 GMT

Когда дело доходит до миграции в облако, можно выделить два основных ключа успеха этого процесса.

Во-первых, начинайте с малого. Это означает сфокусироваться на одной простой среде приложения. При перемещении в облако мы будем внедрять инструменты и запускать приложение в новой среде. Эти изменения могут затруднять определение того, насколько успешно перемещено приложение. Чем больше мы знаем о перемещаемом приложении или сервисе, тем больше шансов на успех.

Во-вторых, определите как успех выглядит для Вас, команды, организации. Шаги, предпринимаемые сейчас, готовят почву для успеха в будущем.

Миграция в облако - это нечеткое понятие и может выполняться по различным причинам. Некоторые из этих причин повлияют на то, сколько изменений вы готовы выдержать в процессе миграции в облако.

Поскольку работа будет осуществляться на оборудовании, находящемся под Вашим контролем, необходимы четкие представления о работоспособности приложения для правильного распределения количества ресурсов. Отсутствие этой информации может привести к чрезмерным затратам и отсутствию эффективности в сравнении с Вашим опытом работы в локальной среде.

Определение (взаимных) зависимостей

Правильно начинать миграцию с понимания того, с чем связано приложением. При миграции в облако некоторые сервисы и данные могут оставаться локальными и необходимо убедиться, что приложение сможет получить к ним доступ. Некоторые необходимо перенести в облако и разместить рядом с приложением. Пока нет четкого понимания, с чем связано приложение, существует риск нарушить поведения приложения в процессе перемещения.

Application Insights

Полезным инструментом в этом процессе является Application Insights. Хотя его основной функцией является мониторинг приложения, Application Insights может использоваться для формирования осведомленности о службах, к которым подключается приложение. Существует 2 основных метода интеграции Application Insights - Codeless Attach и с использованием SDK.

И хотя Application Insights - служба, работающая в Azure, Вы не ограничены в использовании только приложений Azure. Application Insights также предлагает простой доступ к рабочим нагрузкам, работающим в IIS через IIS (или Status Monitor М2).

Application Map

Application Map помогает визуализировать и отслеживать проблемы в распределенных приложениях.

Предположим, что большинство приложений обладает некоторыми внешними зависимыми объектами. Приложения без зависимых объектов обычно называются устройствами или виртуальными устройствами. Это, как правило, автономные экосистемы, где у Вас нет достаточного контроля.

Почти у всего остального есть какие-либо взаимодействия, и Application Map помогает обнаружить их. Это особенно полезно для приложений, когда нет команд, назначенных для их обслуживания или предоставляемых подрядчиками или консультантами.

Codeless Attach

Поговорим о сборе данных с помощью Application Insights. Первый метод - Codeless Attach- позволяет Application Insights отслеживать приложение без изменения кода. Настроить его на Windows Server довольно просто.

Сначала, установите модуль Power Shell Az.ApplicationMonitor.

Enable-ApplicationInsightsMonitoring -ConnectionString xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Теперь любое приложение, которое еще не ссылается на Application Insights SDK будет автоматически инструментировано.

Важный момент: если у приложения уже есть SDK, тогда нужно настроить приложение через код или файл конфигурации, чтобы связать с Application Insights. Это также означает, Вы не будете нарушать существующий мониторинг Application Insights, подключив его для других неинструментированных приложений.

Вы можете проверять состояние каждого веб-сайта в IIS с помощью Get-ApplicationInsightsMonitoringStatus cmdlet.

Другой вариант - включить Application Insights SDK в приложение. Недавние шаблоны .Net приложений уже включают Application Insights SDK; в таком случае речь идет о конфигурации инструментального ключа или о строке подключения.

Но Вы можете сделать гораздо больше: настроить отображение приложения в Application Map, установив имя облачной роли и/или имя облачного экземпляра. Несмотря на имена свойств, они могут быть использованы независимо от того, где запущено приложение. Они помогают идентифицировать приложение и сервер (или экземпляр сервиса), на которых запущено.

После того как приложение инструментировано, Вам нужно дать ему время поработать. Некоторые зависимости могут быть часто недоступны, поэтому продление периода обнаружения - на дни, недели или даже месяцы может помочь выявить доступные ресурсы.

В то время как Application Insights запущен для сбора сведений Application Map, у Вас есть возможность собирать данные о производительности. Это может стать основой того, как приложение должно работать в облаке. Вы увидите вызовы из приложения в зависимости. Это поможет оценить необходимость перемещения зависимости в облако (или же ее можно оставить локально на какое-то время), эффективность сервиса SKU, на котором Вы работаете: нужно ли его масштабировать или у Вас есть место для его уменьшения и экономии денег.

Теперь, когда у Вас есть какие-то данные о приложении и его зависимостях, можно приступать к планированию миграции.

Перемещение приложения и базы данных вместе имеет смысл, учитывая тесную связь и зависимость производительности страницы от результатов работы базы данных.

Ключевые принципы развертывания с использованием архитектуры в масштабе предприятия

Fri, 30 Apr 2021 04:54:26 GMT

Итак, Вы приняли решение сделать Azure частью своей IT-стратегии. У команды есть опыт локального развертыванием инфраструктуры и сейчас важно изучить возможности запуска рабочих нагрузок в Azure.

Погружаясь в любой новый проект, есть ключевые моменты проектирования и принятия решения, которые должны быть обсуждены и поняты на старте. Развертывание зоны размещения корпоративного масштаба и последующих ресурсов в облаке не отличается. Архитектура в масштабе предприятий основана на принципах проектирования, которые служат компасом для проектных решений в критических технических областях.

Команде необходимо обсудить критические области проектирования, изложенные в документации по зонам размещения в масштабе предприятия. Вот только несколько важных пунктов:

Регистрация корпоративного соглашения и участников Azure Active Directory
Управление идентификацией и доступом
Административна группа и организация подписки
Топология сети и подключения
Управление и мониторинг
Непрерывность бизнеса и аварийное восстановление
Безопасность, управление и соблюдение требований
Автоматизация платформы и DevOps

Подписки и управление

Один из первых пунктов, о котором необходимо подумать - настройка среды с точки зрения иерархии административных групп и ответственных лиц за операции платформы. Существует множество способов сегментирования среды. Начните с определения критерия конфигурирования подписки и обязанностей ее владельца. Это позволит создать кросс-функциональную команду платформы DevOps для создания, управления и администрирования архитектуры. Команды разработчиков приложений DevOps получат разрешения владельца подписок на создание и управление источниками приложений с помощью модели DevOps.

Использование подписок для разделения среды помогает с управлением затратами и повседневными обязанностями по управлению.

Некоторые предложения для владельцев подписки:

Выполняйте проверку доступа в Azure Active Directory (Azure AD) Privileged Identity Management ежеквартально или дважды в год, чтобы гарантировать, что права доступа не распространяются по мере перемещения пользователей внутри организации клиента.
Возьмите полную ответственность за расходование бюджета и использование ресурсов.
Обеспечьте соблюдение политики и внесите корректировки при необходимости.

Работа в сети

Работа в сети и то, как Вы хотите, чтобы действовала среда- автономно или интегрировалась в существующие среды- будут важной частью встреч по проектированию. Необходимо спланировать IP-адресацию, систему доменных имен, разрешение имен, топологию, шифрование сети и требования к проверке трафика, гибридное подключение.

У каждой организации будут свои требования, существующие настройки и сложности, которые необходимо преодолеть на пути внедрения облачной стратегии. Обсудив потребности и варианты, команде важно посоветоваться с партнером Microsoft, чтобы использовать внешний опыт и убедиться, что выбранное направление верное.

Безопасность, управление и соблюдение требований

Предположим, у Вас есть некоторые проблемы с текущей средой. Например, пароли и секретная информация хранятся в защищенной таблице excel. Кроме того, большинство локальных источников нарушают соглашение об именах компании, поэтому важно избежать проблем при переходе в облако.

Для паролей и секретной информации вместо таблицы excel лучше использовать Azure Key Vault. Тем не менее, обязательно убедитесь, что разрешения настроены верно, а сотрудники ИТ-отдела готовы к тому, что будут видеть только то, что нужно.

Внедрение Azure Policy упростит соответствие новых ресурсов соглашению об именовании компании.

Лучшие друзья DevOps инженеров

Fri, 30 Apr 2021 04:41:25 GMT

Средства обеспечения производительности - лучшие друзья DevOps инженеров, способные помочь в создании отличного кода. Эти бесплатные инструменты помогают сэкономить время, взаимодействовать и общаться в проектах. Они помогают в тестировании приложений с использованием повторяющейся инфраструктуры, совместной работы и коммуникации.

Инструменты разработки/повышения производительности

Здесь приведен список инструментов, помогающий улучшить производительность разработчика. Приведенные инструменты существуют некоторое время и уже зарекомендовали себя с самой лучшей стороны среди разработчиков DevOps.

Vargant

Среди инструментов DevOps Vagrant широко используется для разработки и тестирования, для имитации производственной среды.

С помощью Vagrant разработчики могут настраивать виртуальные машины, импортируя блоки (шаблоны виртуальных машин) из облака Vagrant, устанавливая параметры виртуальных машин (такие, как сетевое хранилище, и т.д.) и запуская инструменты конфигурирования, например, Puppet или Chef.

Преимущество Vagrant - наличие множества стеков приложений, которые поставляются в составе блоков vargant. Например, если Вы хотите разрабатывать на стеке LAMP, вы можете найти блок LAMP в облаке Vargant. Он содержит список всех доступных блоков, разработанных сообществом с версиями LAMP. Использование этих блоков помогает экономить время на настройке приложений вручную.

Vargant позволяет запускать среды, помещенные в песочницу, не нарушая конфигурации рабочей станции. Например, если нужны среды разработки Python 2 и 3, у Вас могут быть два блока vargant, работающих на python 2 и 3.

Кроме того, у Вас могут быть свои модули puppet, справочное руководство, или набор сценариев Ansible, которые будут использоваться в конфигурационном файле vargant, автоматизирующем конфигурацию с использованием руководства, модуля или набора сценариев.

Варианты использования Vargant

Для повторяющихся сред разработки: Вы можете делиться файлом vargant с другими разработчиками, которые будут запускать ту же виртуальную машину, что и у Вас. Это позволяет избежать медленного перемещения конфигурации между конфигурациями рабочих станций разработчиков.

Нагрузочное тестирование/ Имитация производственной среды: Вы можете развернуть блоки vargant за считанные секунды для нагрузочного тестирования или тестирования производительности, затем ликвидировать их. Также, Вы можете создать производственную среду, объединив блоки vargant вместе.

Docker

Если Вы разработчик, то несомненно полюбите этот инструмент. Docker - инструмент с открытым исходным кодом, позволяющий разработчикам создавать и управлять приложениями в контейнерах Linux.

Docker Hub - онлайн хранилище образов Docker, позволяющее загружать заранее подготовленные образы Docker с большинством стеков. Разработчикам не нужно создавать виртуальные машины или смешивать существующие конфигурации рабочей станции - они могут просто начать работу над приложениями, используя образы docker.

Запуск контейнера осуществляется менее, чем за секунду.

Дополнение Docker – Kinematic. Оно помогает установить движок Docker в системе. Kinematic автоматизирует установку движка, машины, виртуального блока backend и других компонентов docker.

Kinematic обладает превосходным графическим интерфейсом пользователя для управления контейнерами docker. Среди других функций Kinematic следует отметить возможность поиска образов, переключения между интерфейсом командной строки и графическим интерфейсом пользователя, управления портами, конфигурации переменных, журналов сред и т.д. Docker - подходящий инструмент для создания изолированной среды.

Вы так же можете разворачивать контейнеры в блоке vargant, если не хотите использовать приложение с графическим интерфейсом.

Packer

Если Вы относитесь к тем, кто работает с облачными виртуальными машинами, то этот инструмент для Вас. Он автоматизирует создание образа для Вашего облачного провайдера. Также, конфигурации, написанные с Packer, являются cloud-агностическими.

Вы можете писать конфигурацию packer для создания образа для определенного стека приложения и использовать его с несколькими облачными провайдерами.

Кроме того, Вы можете использовать «provisioners» (Shell, Ansible, Chef и т.д.) для автоматизации конфигурации приложения в образах виртуальных машин.

Инструменты непрерывной интеграции

Непрерывная интеграция больше не является процессом, которому следует разработчик. Когда доходит до практики DevOps, даже инфраструктурный код должен следовать практикам непрерывной интеграции. Давайте рассмотрим некоторые решения с открытым исходным кодом для целей непрерывной интеграции.

Jenkins

Jenkins - распространенный инструмент непрерывной интеграции с мощной поддержкой сообщества. Просто установите и используйте для работы с проектами Java или .Net. Образы Docker доступны для большинства версий Jenkins.

Github Actions

Если Ваш код на Github , то можете использовать Github Actions для непрерывной интеграции, создавать определенные рабочие процессы для автоматизации процесса сборки и выпуска. У него есть растущий список интеграций со всеми облачными инструментами и инструментами с открытым исходным кодом.

Travis CI

Travis CI - облачная платформа для непрерывной интеграции. Вы можете использовать ее для проектов с открытым исходным кодом. Она совершенно бесплатна, а для непрерывной интеграции самостоятельная настройка не потребуется.

Системы контроля версий

Лучшей практикой является передача даже одного файла сценария в систему контроля версиями. Инженеру DevOps необходимо следовать рекомендациям разработки и использовать системы контроля версиями для кода, который он пишет.

GitHub

Инструмент разработки является неполным без GitHub- службы размещения репозиториев. Он предлагает контроль версий, функциональность SCM, функции совместной работы такие, как отслеживание ошибок, управление задачами и другое. Он также предлагает функции социальных сетей, например, подписчики и каналы.

Разработчики могут получить доступ к публичным репозиториям и предоставить их исходный код. Кроме того, будучи самым крупным репозиторием в мире, управление запросами и отслеживание проблем становится пустяковым делом.

Bitbucket

Bitbucket - совместная система контроля версий, использующая Mercurial и Git. Разработчики могут получать доступ к безлимитным бесплатным частным репозиториям, управлять или делиться репозиториями, совместно работать над кодом и многое другое. Bitbucket интегрирован с JIRA - инструментом управления проектом.

Gitlab

Если Вам нужна настройка подобная Github, переходите в Gitlab. Настроив один раз, Вы можете использовать ее для размещения кода приложения. Если же Вам не нравится настраивать программное обеспечение, Вы можете использовать образ Gitlab docker для настройки одной строки.

Облачные службы

Работа не всегда происходит на рабочих станциях. Иногда возникает необходимость временной рабочей среды, которую можно разворачивать по требованию и сворачивать, если в ней нет необходимости. Тогда в игру вступает облако.

С помощью таких опций как AWS, DO, Lightsail разработчики могут настраивать собственный виртуальный частный сервер несколькими кликами и платить только за пропускную способность по часам.

AWS

AWS предлагает мощное решение с виртуальными машинами и несколькими другими службами для разработки сайтов или приложений.

AWS - обязательное приложение для разработчиков, ищущих надежную инфраструктуру и недорогие хостинговые решения.

DigitalOcean

DigitalOcean предлагает виртуальные машины с невероятно быстрой скоростью и потрясающими инструментами для разработчика. Облачные экземпляры в DO, называемые каплями, могут быть развернуты в течение всего 55 секунд. Интеллектуальные стратегии, недорогие решения и лучшие облачные предложения внесли ценный вклад в развитие рынка.

Lightsail

Еще один отличный продукт от технологического гиганта Amazon - Lightsail - предлагает разработчикам возможность настройки собственного VPS всего в 3 клика. Разработчики могут воспользоваться преимуществом AWS без необходимости изучения сложных сервисов. Всю сложную работу сделает Lightsail - Вы можете сосредоточиться на важных задачах.

Инструменты взаимодействия/коммуникации

Slack

Slack - прекрасный инструмент для онлайн общения. Он интегрирован со множеством приложений, такими как Google Calendar, Skype, Trello, GitHub, Jira и многое другое. Если Вы в поисках инструмента для мозговых штурмов, общения и взаимодействия, Slack - то, что нужно.

Trello

Trello - инструмент для управления проектами, в котором проекты размещаются на досках.

Asana

Asana - прекрасный инструмент, который помогает во взаимодействии с партнерами, в управлении проектами.

Пользуйтесь этими инструментами и будете успешны в работе.

EXTENDED EVENTS: Обойти XML

Wed, 31 Mar 2021 07:53:56 GMT

Работать с XML - сплошная боль. Писать запросы против XML действительно трудно. Если бы не существовало способов избежать XML, вряд ли кто-то выступал бы за Extended Events. Давайте рассмотрим способы, позволяющие не использовать в работе XML.

Окно Live Data

Концепция проста. Если кликните правой кнопкой мыши на любом сеансе Extended Events внутри SSMS, если это активный сеанс, увидите пункт меню: Watch Live Data. Кликнув на него, откроется окно Live Data. Здесь мы сталкиваемся с проблемой, не менее серьезной, чем XML. Вот результат при первом открытии:

В верхней части экрана расположены все события. В таком случае я собираю запросы через sql_batch_completed and rpc_completed. Выбор любого события в верхней части экрана покажет детали этого события внизу экрана.

Extended Events - универсальное средство просмотра любого события. Но можно настроить и просмотр сеанса. Более того, эта настройка сохраняется автоматически и будет использована повторно.

Итак, как же это работает? Два способа.

Первый: правой кнопкой мыши щелкните на деталях в любом из этих полей. Откроется следующее меню

Щелкните на Show Column in Table и это поле добавится на экране над деталями.

Второй: правой клавишей мыши щелкните в верхней части, прямо в верхней части сетки. Вы получите меню, которое выглядит так:

Щелкните на “Choose Columns…” Откроется новое окно:

Не будем вдаваться в детали, как с этим работать. Слева есть данные, собранные событиями, определенными в Вашем сеансе. Переместите их вправо, чтобы создать собственное представление. Например, вот представление, которое я использую чаще всего при просмотре данных производительности запросов:

Запрос виден как в качестве пакета, так и оператора, продолжительность, CPU, чтение, запись и все это в хорошем аккуратном формате. Более того, даже после того, как Вы это сделаете, останется возможность щелкнуть на любую заданную строку и посмотреть детали. Теперь Вы обладаете всеми видами дополнительной функциональности. Вы можете искать эти столбцы, можете сортировать, группировать и агрегировать, настраивать фильтр данных по времени, или любому столбцу и значению. Короче говоря, у Вас есть инструмент исследования данных, не прибегая к использованию XML.

Но это подходит для небольших фрагментов данных. В качестве альтернативы, файлы можно открывать напрямую. Можно настроить представление данных и затем повторно использовать эту настройку, не проводя дополнительной работы. Вы даже можете сохранить её, передать коллегам или разместить на нескольких машинах.

DBATools

Если вы до сих пор не сталкивались с DBATools, тогда Вас ждет приятная неожиданность. Это набор инструментов PowerShell, который полностью изменит способ администрирования и работы с SQL Server. А его стоимость равна нулю.

DBATools обладает функциональностью Extended Events уже многие годы. И это не просто одна или две команды. Целый ряд функций помогают работать и поддерживать Extended Events.

Теперь, используя DBATools, вам не нужно пытаться понять XPath. Вместо этого, Вы можете запросить файл непосредственно в удобочитаемой форме. Более того, т.к. Вы уже в PowerShell, просто передайте файл в любой другой формат или расположение.

Заключение

Используя эти два метода и ничего более, Вы можете легко обойти XML. Extended Events не сложны в использовании. А даже очень просты.

У всех новых функций в SQL Server есть Extended Events, Trace Events вообще отсутствуют. База данных Azure SQL позволяет использовать только Extended Events. В них больше функциональности, а нагрузку они создают в разы меньше.

Код-ревью и DevOps

Wed, 31 Mar 2021 07:53:53 GMT

На этот вопрос можно дать несколько ответов. Давайте кратко рассмотрим их.

Система управления версиями

Если Вы автоматизируете развертывания, наверняка у Вас есть код в системе управления версиями. Итак, если необходимо провести код-ревью, система управления версиями - прекрасное место для старта. Честно говоря, возможно, это наилучшее место. Можно легко запустить отчет на выбранную базу данных и найти все изменения, произведенные с момента последнего ревью. Независимо от того, проводите ли Вы ревью еженедельно, ежедневно или ежечасно, найти изменения будет легко благодаря системе управления версиями. Но лучше всего, то, что можно наблюдать за изменениями по мере их возникновения - не нужно ждать окончания развертывания.

Более того, если Вы фиксируете скрипты изменений, используемые для развертывания в рабочей среде (кстати, отличная практика), то всегда можете просматривать эти скрипты, чтобы понять, что изменилось. Да, это ревью по факту, но при этом отличный способ следить за тем, что происходит с серверами.

Непрерывная интеграция

Вероятнее всего, если Вы автоматизируете развертывания, у Вас есть механизм начального тестирования, возможно, форма непрерывной интеграции. Это первое место развертывания кода из системы управления версиями. Это отличное место, чтобы увидеть происходящие изменения. Кроме того, процесс CI скорее всего включает отчет об ошибках. Это возможность поймать плохой код на ранних этапах процесса. Здесь также возможно зафиксировать скрипты изменений, используемых для развертывания в среде CI.

Шаг ревью

Просто добавьте шаг ревью в большинство инструментов DevOps. Сделайте одобрение частью процесса. Вы можете легко получить артефакт, созданный для развертывания, посмотреть код до того, как он попадет в продакшн и при этом у Вас будет полностью автоматизированное развертывание в производственной среде. Если же в организации требуются другие подтверждения, они могут быть также внедрены с помощью такого же метода.

Некоторые разработчики настаивают на ревью каждой строчки кода перед развертыванием: открывают сценарий из 10 000 строк, просматривают первые пару, подтверждают, что он компилируется и дело сделано! Часто, шаг код-ревью происходит из-за отсутствия другого тестирования, другого подтверждения кода перед развертыванием в продакшн Если же есть настроенный процесс CI, среда тестирования, промежуточная среда, они все тестируют развертывания. Если создано дополнительное автоматизированное тестирование, оно также подтверждает развертывание. Вместо того чтобы полагаться на Mark I. опирайтесь на процесс, который сделает код-ревью.

Заключение

Используйте инструменты и методы, чтобы убедиться в правильном понимании происходящих изменений. Несмотря на стремление ускорить выпуск релизов, хочется быть уверенными в надежности. Наличие этих процессов гарантирует безопасное развертывание и методы получения знаний о том, что развертывается, добавляет защиту нашим производственным средам.

4 технологических тенденции, которые повлияют на аналитику данных в 2021 г

Wed, 31 Mar 2021 07:53:49 GMT

Статус аналитики данных до 2021 года не был так высок как сегодня. Столкнувшись с пандемией, правительства стран полагаются на углубленное статистическое моделирование для осмысления потока постоянно меняющихся показателей. Специалисты по обработке данных в этом процессе играют не последнюю роль: консультируют первых лиц компаний, стремящихся внедрить правильные политики в нужное время.

Важно понимать, получение выводов из данных - нечто новое. За последние месяцы стремительное развитие сложных инструментов для анализа в режиме "реального времени", стало тенденцией в развитии компаний. И пока предпосылок к ослаблению нет. Развитие искусственного интеллекта и машинного обучения продолжит трансформировать способы проектирования, совместного использования и внедрения данных; помогут установить новые ориентиры в таких понятиях как доступность, скорость получения выводов, диапазон применения, а также усиление роли в принятии решений.

В этом году четыре тенденции будут господствовать в области разработки:

Расширенная аналитика

Это следующий этап в аналитике данных. Веские причины, по которым расширенная аналитика вышла на первый план, определены еще в 2017 г. Помимо прочего, объем информации, доступный организациям, делает эффективную интерпретацию сложным процессом. К 2025 г количество IoT соединений достигнет 5 миллиардов по сравнению с 1,3 млрд в 2019 г. Кроме того, у выводов, полученных на основе данных, короткий срок годности. Если информация не попала к лицу, принимающему решения, через небольшой промежуток времени их ценность равна нулю.

Машинное обучение и искусственный интеллект идеальны для автоматизации и ускорения трудоемких участков работы специалиста по обработке данных. Однако значение расширенной аналитики будет далеко выходить за рамки облегчения работы загруженных специалистов. Сделав сложные инструменты доступными для широкой аудитории, расширенная аналитика повысит возможности специалистов по обработке гражданских данных. Исполнителям работ будут предоставлены инструменты контроля, необходимые для более быстрого принятия решений.

Непрерывный интеллектуальный анализ данных

Стремительное развитие непрерывного интеллектуального анализа данных отражает скорость, с которой работают современные предприятия. Чтобы принять правильное решение, нужно знать, что сейчас происходит. Начиная с 2021 г, большинство ответов будет поступать от непрерывного интеллектуального анализа данных. Обрабатывая текущие и исторические данные, непрерывный интеллектуальный анализ гораздо чаще будет использоваться для автоматизации, чем для поддержки процесса принятия решения.

Инструменты, используемые непрерывным интеллектуальным анализом данных разнообразны. Сюда входят расширенная аналитика, а также обработка потока событий, оптимизация, управление бизнес-правилами, машинное обучение. 2020 г дал понять, что подход "установил и забыл" уже не работает. Меняются рынки, поведение, постоянно что-то происходит. Непрерывный интеллектуальный анализ укрепит позиции в 2021 г: он предоставляет инструменты, которые учатся сами по себе, постоянно корректируясь и совершенствуясь. Так же как и расширенная аналитика, непрерывный интеллектуальный анализ встроится в рабочие процессы, перестав быть привилегией специалистов по обработке данных.Расширенное управление данными, Data Discovery, Каталоги данных. Это также станет новостью в 2021 г. Опять же, это возможности машинного обучения и движки искусственного интеллекта, которые приводятся в действие. В этом случае они будут использоваться для поиска и понимания данных и создания категорий управления корпоративной информацией, включая качество данных, управление метаданными, управление основными данными и интеграцию данных, а также системы управления базами данных (DMS), самонастраивающиеся.

Автоматическое машинное обучение /Объяснимый искусственный интеллект

Как упоминалось, в 2021 году произойдет ускоренный сдвиг в сторону автоматизации процесса принятия решений. Однако зачастую организациям все равно придется исследовать и обосновывать, как принимаются такие решения. Поэтому руководителям важно уметь создавать модели, которые можно интерпретировать и объяснять. Подход “черного ящика”, используемый некоторыми решениями, служит только для того, чтобы отгородиться от пользователей. Вместо этого аналитики все чаще будут искать ответственный, объяснимый и интерпретируемый искусственный интеллект. Эта прозрачность дает уверенность в результатах, возможность специалистам по обработке данных учиться и расти вместе со своими системами. Кроме того, модели могут быть модифицированы и точно настроены в соответствии с постоянно меняющимися условиями окружающей среды. В 2021 году и последующие годы не должно быть необходимости выбирать между автоматизацией и демократизацией. При наличии правильных решений они будут идти рука об руку.

6 рекомендаций для успешного внедрения стратегии управления данными

Wed, 31 Mar 2021 07:53:44 GMT

Управление данными - сложное поле деятельности, поэтому внедрение и поддержание стратегии сталкивается с рядом сложностей. К счастью, тысячи, если не миллионы организаций используют управление данными для улучшения операционной деятельности, поэтому у Вас есть уникальная возможность учиться на чужих ошибках и успехах.

1. Сфокусируйтесь на операционной модели

Операционная модель, иногда называемая моделью активов, описывает как в организации определены роли, обязанности, бизнес-термины, области данных и т.д. Это влияет на рабочие процессы, функции, на то, как организация работает с данными.

Операционная модель - основа для любой программы управления данными. Идея состоит в создании структуры управления предприятием. В зависимости от организации, структуры могут быть:

Централизованными (все управление происходит центральным органом)
Децентрализованным или федеративным (существует несколько групп полномочий)

Пример операционной модели:

Кросс-функциональная страховая компания, часто требуется сотрудничество между различными направлениями бизнеса, такими как финансы, продажи, маркетинг и ИТ. В каждом отделе есть свой представитель по управлению данными, бизнес-стюарды (собственники данных) и технические стюарды (собственник инфраструктуры, поддерживающей данные).

Компания создала структуру управления корпоративными данными и сформировала совет по управлению данными, подотчетный директору по данным. Определение прав помогает социализировать программу и создавать интеллектуальную структуру для прорабатывания программ данных как единого целого.

Представители бизнеса и ИТ формируют различные группы и выстраивают структуру отчетности, часто называемую советом или комитетом по управлению данными. Совет обсуждает проблемные вопросы, связанные с данными, принимает решения и распространяет информацию по всей организации. Совет по управлению данными определяет правильные инструменты и технологии для поддержки стюардов, чтобы те, в сою очередь, могли выполнять свою работу эффективно.

2. Определите области данных

После создания структуры управления данными следующая рекомендация - определение областей данных для каждого направления бизнеса. Наиболее популярные примеры: области данных клиентов, вендоров и продуктов. Каждая область содержит следующие артефакты:

Собственники данных
Бизнес-глоссарий
Словари данных
Бизнес-процессы
Каталоги данных
Каталоги отчетов
Показатели качества данных
Системы и приложения
Политики и стандарты

Обычно организации определяют области данных, когда сталкиваются с проблемами.

Пример

Это пример компании, предоставляющей финансовые услуги, которая преодолела проблемы с данными и следовала методу определения областей данных.

У фирмы были трудности с доступом к данным, а ей хотелось получать больше информации о клиентах. Требования компании, связанные с этими бизнес-проблемами, включали:

Повысить уровень удовлетворенности клиента
Контролировать проверку потребностей клиентов
Увеличить объем дополнительных продаж

Данные были рассредоточены по разным системам и приложениям без определения владельца.

Фирма создала принадлежность путем определения ключевых заинтересованных сторон, бизнес-процессов и наборов данных, относящихся к предметной области клиентов, и установила контроль над ее жизненным циклом. Это дало пользователям данных ясное понимание, откуда приходят данные, кто их собственник, когда они изменяются и кто должен быть привлечен.

Это простая диаграмма для области данных "Клиент", демонстрирующая все стадии происхождения данных в области.

3. Определите критические элементы данных в областях данных

На ранних этапах Вашей программы управления данными нет необходимости сосредотачиваться на всех артефактах сразу. Важно определить критические для бизнеса.

Рассмотрим на примере технологической компании. Компания нуждалась в управлении данными для подтверждения отчетов клиентов и связанных с ними источников. На первой стадии внедрения компания определила только 10 наиболее важных отчетов и зафиксировала информацию о системах происхождения. Позже, инициатива была расширена, применив сертификационные требования и соответствующую исходную информацию для всех отчетов. Проще говоря, отчет не сертифицируется, если собственники не могут показать его отслеживаемость в системе происхождения.

4. Определите контрольные измерения

Управление данными - это не разовый проект. Это постоянная программа для принятия решений на основе данных и создания возможностей для бизнеса. Она готовит организацию к соблюдению бизнес-стандартов. В контрольные измерения входят следующие ключевые активности:

Определение автоматизированных рабочих процессов и пороговых значений для утверждения, эскалации, проверки и разрешения проблем.
Применение процессов последовательности операций к структуре управления, области данных и критическим элементам
Разработка отчетности по реализации программы
Получение обратной связи с помощью автоматизированных процессов
Последовательная коммуникация

5. Эффективная коммуникация

Одним из преимуществ управления данными является то, что оно помогает создать общий язык, ведь эффективная коммуникация - лучший метод управления данными. Рассмотрим три сегмента коммуникации: вовлеченность, адаптация и принятие.

Вовлеченность

Управление данными оказывает влияние на каждое подразделение организации, поэтому важно убедиться, что руководители понимают ценность стратегии. Расскажите им, как управление данными поможет достичь стратегических целей, каковы риски и последствия, если они не будут участвовать.

Адаптация

К сожалению, не достаточно просто щелкнуть пальцами и всем сразу станут понятны тонкости управления данными; необходимо обучать процессам управления данными. Необходимо донесение ценности управления данными и информирование о том, как управление данными влияет на повседневную жизнь.

Принятие

И наконец, Вам необходимо последовательно и планомерно доносить информацию о ценности управления данными, чтобы руководители и пользователи могли применять методы и технологии управления данными. Вы можете сделать это с помощью:

Встраивания оповещений и уведомлений об управлении данными в ваши инструменты
Проведения сессий обновлений
Отчетности по показателям управления данными и прогрессу.
Предоставления обновлений об изменениях политики

6. Измеряйте свои цели с помощью метрик

Вашим командам необходимо оценивать прогресс программы управления данными и ее влияние на остальную организацию.

Эта рекомендация является наиболее сложным, но важным элементом для обеспечения непрерывного совершенствования.

Первый шаг - понять и определить, как выглядит успех. Ваш успех не будет похож на успех других организаций. Он будет зависеть от Ваших целей. Задайте вопрос себе и вашей команде

Как выглядит успешная программа управления данными?
Что значит достичь Data Intelligence?
Как мы узнаем, что достигли Data Intelligence?

Ответив на эти вопросы, Вы сможете определить цели и критерии оценки. Ключевые показатели производительности должны соотноситься с целями и стратегиями. Некоторые области для отслеживания

Разработка словаря данных и бизнес-глоссария - отслеживайте количество терминов и активов, которые Вы загружаете в систему.
Доступ - отслеживайте, сколько времени требуется пользователям для получения необходимой информации.
Принятие - определите, как много сотрудников используют технологию управления , как часто и как долго.
Разрешение проблем - подсчитайте, сколько проблем, связанных с данными, регистрируется в вашей организации и оцените, насколько хорошо команда решает эти проблемы, как много и как долго.
Качество данных - контролируйте чистоту доступных данных и их соответствие целям.
Соответствие политике - измерьте, в какой степени организация придерживается стандартов, установленных внешними и внутренними регуляторами.
Повторное использование и масштабируемость – ведите учет того, каким процессам ваша организация следует чаще всего и как они развиваются с течением времени.
Финансовая рентабельность инвестиций – рассчитайте финансовое влияние управления данными на организацию

Управление ресурсами Azure с помощью задач автоматизации

Wed, 24 Feb 2021 11:36:43 GMT

Существуют различные способы управления ресурсами в зависимости от потребностей. С помощью задач автоматизации Azure предлагает простой способ управления ресурсом или группой ресурсов, используя шаблоны задач автоматизации. Эти шаблоны зависят от ресурса. Например, для виртуальной машины Azure вы можете создать задачу автоматизации, которая включает или выключает виртуальную машину по заданному расписанию или отправляет отчет о стоимости ресурса. Это особенно полезно, если Вы пытаетесь снизить стоимость ваших виртуальных машин Azure.

Задача автоматизации - это фактически рабочий процесс, который на самом деле работает в службе Azure Logic Apps. Задачи автоматизации в настоящее время находятся в предварительном просмотре и поддерживают отправку ежемесячной стоимости всех ресурсов Azure и специальных шаблонов для виртуальных машин, учетных записей Azure Storage и Azure Cosmos DB.

У Вас может возникнуть вопрос: в чем отличие задач автоматизации от Azure Automation? На сегодняшний день задача автоматизации может быть создана на уровне ресурсов, доступен просмотр истории выполнения задачи и изменения логики, лежащей в основе выполнения задачи, которая управляется Azure Logic Apps. Задачи автоматизации более простые и легкие, чем Azure Automation.

Azure Automation – это облачная служба автоматизации и конфигурации, поддерживающая согласованность в управлении между средами Azure и другими средами. Эта служба включает в себя автоматизацию для процессов оркестровки с использованием перечней задач, управление конфигурацией с отслеживанием изменений, управление обновлением, гетерогенные функции; дает полный контроль в процессе развертывания, работы и вывода из эксплуатации рабочих процессов и ресурсов.

Как создать задачу автоматизации

Создать задачу автоматизации очень просто. На портале Azure найдите ресурс, которым хотите управлять, в меню ресурсов перейдите в раздел Автоматизация (Automation) и выберите Задачи (Tasks).

Теперь Вы видите существующие задачи автоматизации или можете кликнуть на "Добавить" (Add) и добавить новую задачу из шаблона.

Вы можете выбрать шаблон, который хотите использовать. В разделе "Аутентификация" (Authentication) обозначены необходимые подключения к этой конкретной задаче.

В разделе Конфигурация (Configuration) Вы можете добавить дополнительную информацию для задачи. В этом примере виртуальная машина запускается каждый день в 10 утра.

После того как задача автоматизация создана, ее можно увидеть в разделе Задачи (Tasks). Здесь вы можете видеть задачи и просматривать выполнения, а также редактировать задачу.

Вы можете провести оперативное редактирование для внесения простых изменений, но также можете открыть его в Logic Apps Designer.

4 примера использования Azure Synapse

Wed, 17 Feb 2021 14:52:37 GMT

Azure Synapse Analytics - это безграничный аналитический сервис, который создан для объедения двух миров больших данных и хранилищ данных в единую платформу.
Azure Synapse предоставляет полное готовое решение, предназначенное для ускорения процесса анализа и повышения гибкости бизнеса. Azure Synapse- единственная сквозная платформа, которая объединяет прием данных, аналитику больших данных и хранение данных; предлагает готовые варианты настройки для быстрого получения результатов, обеспечивает контроль и гибкость с точки зрения ценообразования, позволяя выбирать подходящий вариант для каждой рабочей нагрузки.

Пример №1

Aggreko - мировой лидер по поставкам электрогенераторов, систем контроля температуры и энергетических услуг, обеспечивающих резервное энергоснабжение и энергоснабжение в любое время и в любом месте, где это необходимо клиентам. Aggreko использует Azure Synapse для повышения операционной эффективности.
Конвейер приема данных Aggreko был настроен на запуск каждые восемь часов, потому что для выполнения приема требовалось четыре часа. Кроме того, хранилище данных приходилось перестраивать каждый день из-за ограничений хранения. Это означало, что между поступлением данных и их доступностью для конвейеров задержка составляла в 8-24 часа.

С помощью Azure Synapse, Aggreko улучшила срок анализа данных, уменьшив сложность приема и увеличив скорость. Время приема сократилось с четырех часов до менее чем пяти минут. Это, в свою очередь, означало, что для Aggreko данные теперь доступны для аналитических конвейеров почти в режиме реального времени (с задержкой менее пяти минут). Команда также подсчитала, что они сэкономили 30-40 процентов своего времени, которое было потрачено на решение технологических проблем в устаревших системах. Благодаря внедрению Azure Synapse данные теперь доступны для мгновенного изучения, а это означает, что у команды Aggreko есть больше времени, чтобы сосредоточиться на решении бизнес-задач.

Пример №2

Clearsale, ведущая бразильская компания по обнаружению мошенничеств, использовала Azure Synapse для модернизации платформы оперативной аналитики данных. Ежедневно компания помогает клиентам проверять в среднем полмиллиона транзакций, используя аналитику больших данных с целью выявления подлогов по всему миру. Набор данных Clearsale удваивается каждые два года, при этом компания должна предоставлять услуги в течение нескольких секунд. Это требует большого уровня масштабируемости и производительности:

С помощью Azure Synapse Clearsale сократила время, необходимое для обучения новых моделей для улучшения процесса обнаружения мошенничества. Использование старой локальной платформы требовало 7 дней для приема, подготовки и обучения модели машинного обучения. С помощью Azure Synapse этот показатель сократился до менее чем шести часов. Такое улучшение повысило эффективность и снизило операционные расходы.

Пример №3

Компания GE Aviation - мировой лидер в производстве авиационных двигателей и разработке авиационного программного обеспечения. Кроме этого GE предоставляет расширенную аналитику данных авиакомпаниям по всему миру. Для каждого полета GE принимает серии данных за весь полет, которые включают в себя до 350 000 точек данных. Понятно, что анализ данных в таких объемах данных – сложная задача. Чтобы решить эту проблему, команда выбрала платформу Azure Synapse:

Использование Azure Synapse значительно упростило и ускорило создание сложных прогностических моделей машинного обучения. Встроенная интеграция между Microsoft Power BI и Azure Synapse оказалась чрезвычайно полезной. Теперь данные анализируются быстрее, и когда в отчетах Power BI обнаруживается аномалия, аналитики могут провести детализированный анализ и понять, почему произошли скачки и что необходимо предпринять для корректировки.

Пример №4

Представьте себе крупную транснациональную розничную компанию, у которой магазины в Австралии, Новой Зеландии и Японии. Здесь продаются потребительские товары, электроника и предметы личной гигиены. Аналитика данных нужна компании для создания представления о своих клиентах. Цель состоит в повышении качества обслуживания и увеличении прибыли. Чтобы добиться этого, команда по анализу данных приняла Azure Synapse в качестве подходящей платформы для достижения поставленной цели:

Azure Synapse позволила группе обработки данных объединить свои данные, разработчиков и бизнес-пользователей способами, которые ранее были невозможны. Azure Synapse упростила прием и обработку данных, организацию хранения все операционные и исторические данные, которые могут быть обновлены почти в режиме реального времени. Azure Synapse также упростила исследование и обнаружение данных без необходимости преобразования данных из одного формата в другой или перемещения их в другие системы.

В современных условиях у организаций должно быть четкое представление о результатах деятельности в режиме реального времени для постоянного развития.

Azure Synapse предлагает безграничный, унифицированный, мощный аналитический сервис, который позволяет компаниям начинать с малого и масштабироваться по мере необходимости. Вы платите только за то, что используете, и только тогда, когда вам это нужно.

Использование облачного хранилища данных и важность управление данными

Wed, 10 Feb 2021 12:02:32 GMT

Облаку присущи как операционные, так и конкурентные преимущества, поэтому инициативы в области цифровой трансформации входят в число важных в процессе обработки данных.

Из-за увеличения числа внутренних и внешних нарушений, организациям необходимо согласовывать работы по цифровой трансформации и миграции с другими стратегическими требованиями (например, соблюдение Общего регламента по защите персональных данных).

Сегодня умение ориентироваться в пост-ковидном мире, который заставляет организации становиться гибкими, бережливыми и сосредоточенными на результатах, позволяющих бизнесу не только выжить, но и процветать в новой действительности.

Однако облачная миграция это не только стратегия "lift and shift." Обычно, когда организации переходят из локальной среды в облачную, они преобразуют две различные технологии. Также следует стоит обратить внимание на проблемы, связанные с данными.

Бюджет и затраты

Для 47% компания главная причина миграции в облако - оптимизация расходов. Однако, облачные миграции могут быть дорогостоящими; затраты возрастают по мере увеличения времени миграции.

Компании нечасто выделяют соответствующий бюджет на технологию миграции. В 2020 г организации превысили бюджет на публичные облака в среднем на 23%. Это связано с отсутствием планирования, приводящим к длительной и затяжной миграции и опрометчивым решениям по продукту. Кроме того, ручные миграции занимают больше времени и стоят гораздо дороже, чем автоматизированные.

В разрезе бюджета и затрат, автоматизированные инструменты, сканирующие репозитории в среде, помогают добавить структуру и бизнес-контекст: где находится, кто может получить доступ, и т.д. в момент трансформации устаревших структур. Новые структуры обеспечат новые возможности для данных и бизнес-процессов.

Автоматизированные инструменты помогут снизить риски и расходы, а также сократить время на реализацию проекта. Автоматизированное программное обеспечение работает с каталогизацией данных, локализует, моделирует и управляет облачными массивами данных.

Инструменты для планирования и выполнения облачных миграций несложно найти. Их предлагают крупные облачные провайдеры; они способны упростить миграцию на платформу провайдера. Но независимый от технологий подход к таким инструментам повышает ценность проектов миграции в облако.

Инструменты, предоставляемые поставщиками, ведут клиентов в их среду. Независимые же инструменты помогают понять, какая облачная среда подходит для организаций. Их цель - определить облачную платформу и стратегию, которые принесут наибольшую пользу после определения бюджета и требований к функциям.

Институциональная память

Институциональная память - это другое препятствие, с которым сталкиваются компании при изучении облачных миграций. Покидая компанию, люди уносят с собой понимание того, как и почему осуществлялся порядок действий. Поэтому Вы можете не знать, какие данные есть и как их использовать. Проблема возникает, когда приходит время миграции; необходимо понимать, что есть, как это используется, в чем ценность и что требуется перенести. В противном случае будут потрачены время и деньги на миграцию данных, а в итоге обнаружится, что ими не пользовались несколько лет и необходимости в их переносе не было.

Кроме того, если Вы планируете использовать мультиоблачный подход, важно убедиться, что используемые облака совместимы. Только у 24% ИТ - компаний высокая степень совместимости между облачными средами. Это означает, что более 3/4 компании страдает от неэффективных облачных настроек и отсутствия возможности анализировать данные из нескольких облачных сред.

Управление данными.

Миграция данных в облако - это только половина истории; другая часть - управление ими. Ваши массивы данных должны быть доступны для использования нужными людьми для правильных целей для максимальной безопасности, качества и ценности.

Около 60% предприятий беспокоятся о соблюдении нормативно-правового соответствия, выполнении требований облачных служб, об управлении. Сложность заключается в создании надлежащего процесса управления данными, при этом избегая риска и извлекая как можно больше из этих данных. Более 3/4 (79%) компаний ищут наиболее эффективный вариант встроенных средств безопасности и управления данными, которые размещаются в облаке.

Миграция дает возможность не просто переносить данные такими как есть, но и производить стратегические изменения.

К сожалению, 72% компаний заявляют, что решение о том, какие рабочие нагрузки необходимо перенести в облако - один из барьеров на пути внедрения облачных технологий. Однако облачная миграция - не конечная точка; это всего лишь следующий шаг, чтобы сделать бизнес гибким в долгосрочной перспективе. Определение, какие массивы данных необходимо перенести может помочь подготовиться к росту.

Автоматизированная облачная миграция и управление данными.

Описанные выше сложности облачной миграции могут показаться пугающими, особенно организациям, которые накапливают и управляют огромным количеством данных. Когда компании сталкиваются с ручной, громоздкой работой, касающейся бизнес-процессов, ИТ-инфраструктуры, и т.д., они часто обращаются к автоматизации.

Автоматизированные программные средства могут помочь в планировании и тяжелом подъеме облачных миграций. Они должны учитываться при выборе платформ, прогнозировании расходов, понимании ценности данных, рассматриваемых для миграции.

Автоматизация - критический фактор для инструментов облачной миграции и управления данными.

Ключевые преимущества:

Снижение затрат: автоматические инструменты сканируют репозитории в вашей среде и добавляют структуру и контекст в трансформации устаревших структур.
Сокращение рисков: автоматизированные инструменты сокращают риски, расходы и время на достижение желаемого результата.
Платформенно-независимый подход повышает значение проектов облачной миграции.
Любое облако к любому облаку: автоматический сбор абстрактных сущностей данных упростит передачу информации на другую облачную платформу или технологию, если или когда, вы снова решите осуществить миграцию.
Сохранение институциональной памяти: сбор и сохранение институциональных знаний вокруг данных и обеспечение прозрачности.
Непрерывное управление данными: автоматизация помогает ИТ-компаниям решать проблемы управления данными во время облачной миграции, а затем на протяжении жизненного цикла данных и минимизирует вмешательство человека.

Любая среда и данные уникальны. Поэтому первый шаг в работе - оценить стратегию облачной миграции. Затем составляется дорожная карта автоматизации и разрабатываются стыковочные пакеты «умных данных», чтобы помочь ИТ-службам достичь перспективного состояния архитектуры, включая ускорение приема данных и преобразование ETL.

Безболезненный процесс миграции: что нужно знать

Mon, 01 Feb 2021 06:52:00 GMT

Вы готовы переехать в облако, но не знаете, с чего начать? Тогда эта статья то, что нужно. Здесь будут даны пять советов, в основе которых лежит опыт работы с клиентами по совершенствованию технологии миграции.

Совет №1: Важно знать, зачем нужна миграция в облако.

Убедитесь, что все вокруг тоже в курсе. Обычно миграция не происходит ради самой миграции. Так почему же вы пошли на это?

Необходимость снижения эксплуатационных расходов?

Или увеличения скорости анализа?

От Вас требуется соответствие новым стандартам безопасности? Каждая организация уникальна, поэтому миграция - это стратегический или культурный сдвиг.

Совет №2: Проведите аудит текущих активов.

Некоторые организации ведут текущий учет технических активов и их использования. Эти инструменты будут не лишними в процессе миграции технологий: так Вы знаете, что есть, кто использует и как часто. Аудит также приводит в порядок информацию, разбросанную по множеству документов и спецификаций, и упрощает выполнение текущих и будущих бизнес-требований.

Если вы не делали подобное раньше, а сейчас задумались о том, как начать, создайте типовые варианты использования. Вариант использования - аналитический метод и точка соприкосновения бизнес-пользователей и технических специалистов, которая фиксирует взаимодействие пользователя с технологией.

Документирование вариантов использования включает:

- Определение и описание бизнес-процесса

- Определение пользователей или ролей, которые используют технологию

- Обсуждение входных условий, основного потока, потоков исключений, и постусловий, определенных для каждого варианта использования.

Вы можете думать о вариантах использования как об инструменте, который позволяет задавать вопросы, раскрывающие проблемы в понимании и требованиях. Информация, собранная в ходе этого процесса, фундаментальна; она будет использоваться в словаре данных, в диаграммах "сущность-связь" и графических схемах программ для учета и документирования других текущих ресурсов.

Совет №3: Используйте преимущества перехода

Переходы, включая миграцию технологий, предоставляют возможности улучшения бизнес-процессов и результатов. В Совете №2 мы рассмотрели момент ознакомления с текущими вариантами использования и ресурсами. А теперь, подумайте, как можно улучшить их для максимальной поддержки цели миграции.

Пришло ли время перейти от транзакционной отчетности к аналитическим выводам?

Нужна ли Вам эластичная масштабируемость и высокое время задержки в сравнении с текущим решением?

Можете ли Вы объединить и параметризовать ресурсы для повышения их ценности и охвата?

Какая техника миграции наилучшим образом оптимизирует приложения для достижения бизнес-целей?

Совет №4: У Вас должен быть процесс содержательного проектирования

Важный компонент вовлечения заинтересованных сторон - включение в проектирование процесса миграции.

Содержательное проектирование дает повышенные возможности для каждого. Набор инструментов и методология содержательного проектирования Microsoft - удачное место для старта, которое фокусируется на 3 принципах:

Выявить исключения

Определить для одного, применить для многих.

Обучение на разнообразии

Совет №5: Начинайте с малого

Обязательства, коммуникация и размеры проекта не означают, что Вам необходимо прикладывать чрезмерные усилия по развертыванию с самого начала. Лучший способ проведения эффективных изменения - начать с малого и развивать коллектив. Определите инициативу или приоритет и начините с этого.

Дайте коллективу увидеть и понять воздействие маленькой победы и ее влияние на "почему ".

Философия - думай масштабно, но начинай с малого - помогает доносить ценность изменений для всей организации.