Looking Forward: Some Predictions for 2022

2021-12-31 John Engates

Post Syndicated from John Engates original https://blog.cloudflare.com/predictions-for-2022/

As the year comes to a close, I often reflect and make predictions about what’s to come in the next. I’ve written end-of-year predictions posts in the past, but this is my first one at Cloudflare. I joined as Field CTO in September and currently enjoy the benefit of a long history in the Internet industry with fresh eyes regarding Cloudflare. I’m excited to share a few of my thoughts as we head into the new year. Let’s go!

“Never make predictions, especially about the future.”
— Casey Stengel

Adapting to a 5G world

Over the last few years, 5G networks have begun to roll out gradually worldwide. When carriers bombard us with holiday ads touting their new 5G networks, it can be hard to separate hype from reality. But 5G technology is real, and the promise for end-users is vastly more wireless bandwidth and lower network latency. Better network performance will make websites, business applications, video streaming, online games, and emerging technologies like AR/VR all perform better.

The trend of flexible work will also likely increase the adoption of 5G mobile and fixed wireless broadband. Device makers will ship countless new products with embedded 5G in the coming year. Remote workers will eagerly adopt new technology that improves Internet performance and reliability.

Companies will also invest heavily in 5G to deliver better experiences for their employees and customers. Developers will start re-architecting applications where more wireless “last mile” bandwidth and lower wireless latency will have the most benefit. Similarly, network architects will seek solutions to improve the end-to-end performance of the entire network. In 2022, we’ll see massive investment and increased competition around 5G amongst network operators and cloud providers. Customers will gravitate to partners who can balance 5G network adoption with the most significant impact and the least cost and effort.

The talent is out there; it’s “just not evenly distributed.”

For various reasons, large numbers of workers changed jobs this year. In what has been called “the great resignation,” some claim there’s now a shortage of experienced tech workers. I’d argue that it’s more of a “great reshuffle” and consequently a race to attract and hire the best talent.

Work has changed profoundly due to the global pandemic over the last two years. People are now searching, applying, interviewing, onboarding, and working entirely remotely. Anyone looking to change jobs is likely evaluating potential employers on the working environment more than they did pre-2020.

Jobseekers are evaluating employers on different criteria than in the past. Does video conferencing work reliably? How streamlined is access to the software and tools I use every day? Can I work securely from different locations, or do the company’s security controls and VPN make it difficult to work flexibly?

Employers must make working flexibly easy and secure to attract the best talent. Even small amounts of digital friction are frustrating for workers and wasteful for employers. CIOs must take the lead and optimize the fully-digital, flexible work experience to compete for the very best talent. In 2022, I predict technology and tools will increasingly tip the balance in the talent war, and companies will look for every technological advantage to attract the talent they need.

Cloud Simply Increases

To eliminate some strain on employees, companies will search for ways to simplify their business processes and automate as much as possible. IT leaders will look for tasks they can outsource altogether. The best collaboration software and productivity tools tend to be delivered as-a-service.

It’s easy to predict more cloud adoption. But I don’t expect most companies to keep pace with how fast the cloud evolves. I was recently struck by how many services are now part of cloud provider portfolios. It isn’t easy for many companies to train employees and absorb these products fast enough. Another challenge is more cloud adoption means CEOs are often caught off guard by how much they are spending on the cloud. Lastly, there’s the risk that employee turnover means your cloud expertise sometimes walks out the door.

I predict companies will continue to adopt the cloud quickly, but IT leaders will expect cloud services to simplify instead of adding more complexity. Companies need the cloud to solve problems, not just provide the building blocks. IT leaders will ask for more bang for the buck and squeeze more value from their cloud partners to keep costs under control.

I also look forward to CIOs putting pressure on cloud providers to play nice with others and stop holding companies hostage. We believe egregious egress charges are a barrier to cloud adoption, and eliminating them would remove much of the cost and frustration associated with integrating services and leveraging multiple clouds.

“Everything should be made as simple as possible, but not simpler.”
— Albert Einstein

Security is only getting more complicated. Companies must embrace zero trust

Throughout 2021, Cloudflare observed a steady rise in bot traffic and ever-larger DDoS attacks. As an industry, we’ve seen the trends of more phishing attempts and high-profile ransomware attacks. The recent emergence of the Log4j vulnerability has reminded us that security doesn’t take a holiday.

Given the current threat landscape, how do we protect our companies? Can we stop blaming users for clicking phishing emails? How do we isolate bad actors if they happen to find a new zero-day exploit like Log4j?

The only trend I see that brings me hope is zero trust. It’s been on the radar for a few years, and some companies have implemented point-products that are called zero trust. But zero trust isn’t a product or industry buzzword. Zero trust is an overarching security philosophy. In my opinion, far too few companies have embraced zero trust as such.

In 2022, CIOs and CISOs will increasingly evaluate (or reevaluate) technologies and practices in their security toolkit through the lens of zero trust. It should not matter how invested IT leaders are in existing security technology. Everything should be scrutinized, from managing networks and deploying firewalls to authenticating users and securing access to applications. If it doesn’t fit in the context of zero trust, IT managers should probably replace it.

The security-as-a-service model will tend to win for the same reasons I predicted more cloud. Namely, solving security problems as simply as possible with the fewest headcount required.

The corporate network (WAN) is dead. Long live the (Internet-based) corporate network

I can’t pinpoint the official time of death of the corporate WAN, but it was sometime between the advent of fiber-to-the-home and 5G wireless broadband. The corporate network has long suffered from high costs and inflexibility. SD-WAN was the prescription that extended the corporate network’s life, but work-from-home made the corporate network an anachronism.

Video conferencing and SaaS apps now run better at home than at the office for many of us. And the broader rollout of 5G will make things even better for mobile users. Your old VPN will soon disappear too. Shutting down the legacy VPN should be a badge of honor for the CISO. It’s a sign that the company has replaced the castle-and-moat perimeter firewall architecture and is embracing the zero trust security model.

In 2022 and beyond, the Internet will become the only network that matters for most users and companies. SaaS adoption and continued flexible work arrangements will lead companies to give up the idea of the traditional corporate network. IT leaders will likely cut budgets for existing WAN infrastructure to invest in more effective end-user productivity.

Matters of Privacy

Social media whistleblowers, end-to-end encryption, and mobile device privacy were on the minds of consumers in 2021. Consumers want to know whom they’re buying from and sharing data with, are they trustworthy, and what these companies do with the collected data?

Data privacy for businesses is critical to get right due to the scope of the privacy issues at hand. Historically, as some digital enterprises grew, there was a race to collect as much data as possible about their users and use it to generate revenue. The EU Global Data Protection Regulation (GDPR) has turned that around and forced companies to reevaluate their data collection practices. It has put power back into the hands of users and consumers.

GDPR is just one set of rules regulating the use of data about citizens. The US, EU, China, Russia, India, and Brazil have different views and regulations on privacy. Data privacy rules will not evolve the same everywhere, and it will be increasingly difficult for companies to navigate the patchwork of regulations around the globe.

Just as security is now a part of every software delivery stage, privacy needs to be considered throughout the development process. I predict that in 2022 and beyond, companies will architect applications with privacy laws in mind from the outset. About a year ago, we announced Cloudflare Data Localization Suite, which helps businesses take advantage of our global network’s performance and security benefits while making it easy to set rules to control where their data is handled automatically.

Another trend that spans the domains of privacy, security, and remote work is user preference for a single device for both personal and work-related activities. Carrying two or more devices is a hassle, but maintaining privacy and security on an unmanaged device presents challenges for IT. We will move away from the traditional tightly controlled, IT-managed device with time. Browser isolation and the evolution of zero trust security controls will get us closer to this holy grail of end-user device independence.

Conclusion

We have much to be thankful for, even with the challenges we’ve all faced in 2021. 2022 may well be as challenging as this year has been, but I predict it will be a great year, nonetheless. We’ll work hard, learn from our mistakes, and ultimately adapt to whatever life and work throw at us. At least that’s my plan for next year!

The 2007 Boston Mooninite Panic

2021-12-31 The History Guy: History Deserves to Be Remembered

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=tGqXrV9kjSE

Week 52

2021-12-31 Йовко Ламбрев

Post Syndicated from Йовко Ламбрев original https://yovko.net/week-52/

Week 52

В началото на годината бях с нагласата да увелича малко темпото на публикациите си в блога, но не се получи. От една страна заделих повече време за (уж) по-важни неща. От друга, все по-трудно намирам смисъл да се надвиквам с джангъра на днешния Web, концентриран в пет URL-а и куриран от тенденциозно-злонамерените алгоритми на социалките, които стават все по-нагли, вредни и безполезни.

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

Но от друга страна… отново работя със свестни хора в добра компания. В семейството сме добре и ни е уютно. Сдобихме се с мечтано местенце за почивка (и изолация от шума и претенциите на света). Успяваме засега да се опазим от вируса – цялото семейство, заедно с вече доста възрастната ми майка – с ваксини, бустери и дистанция. Разбира се, тежи да не се виждаме с приятели толкова често, колкото бихме искали. И да не пътуваме както преди. Но повече тежи липсата на перспектива това скоро да се промени към по-добро, най-вече заради африканските нива на имунизация в уж европейска България, където има пълен избор и излишък на ваксини. И където на това отгоре масово не се спазват и най-базовите правила.

Не че съм имал високи очаквания за интелекта и чувството за отговорност на българите. Действителността обаче надмина и най-смелите ми допускания. В негативна посока. Такова ниво на страх, тъпота, егоизъм и недоверие в науката, в комбинация с безхаберие и пълната липса на солидарност към по-болните, по-възрастните и по-застрашените… това вече не се лекува. Безнадеждно е. И явно друго не помага, освен да го отмие времето. Ако изобщо му е останало толкова време на този свят, че да стигне за очовечаване на това твърдоглаво племе.

На този фон нямам особени очаквания за 2022 година. Или по-скоро допускам, че всичко ще стърже и скърца поне до лятото. За добро или лошо живеем в ужасно свързан свят и всичко има значение.

В политически план добрата новина е, че доживяхме финала на латиносериала Борисов. Това обаче още нищо не означава, докато не доживеем разглобяването на модела, който направи Борисов възможен (поне от инициатива „Глобална България“ насам, ако не и още по-назад).

От света на информационните технологии през годината по-скоро нямаше нещо кой знае какво за отбелязване. Интернет става все по-централизиран. Облаците също. А гравитацията и значението им огромни. Съпротивата срещу това е слаба и наистина трудна и ще става все по-зле, доколкото хората, които се вълнуват от моралната страна на технологичния прогрес са почти невидимо малцинство. Днес, сега… Няма по-критично време, в което трябва да се опазят и подпомагат малките в света на технологиите. Но тези, които не преследват ръст на всяка цена. Защото нямаме полза от нови гиганти.

Криптаджиите продължават да надуват балони, по-новите от които са все по-парадоксални (NFT, Web3 и прочие). „Бойте се от данайците, когато ви поднасят дарове.“ Та и криптаджиите пропиляха всичкия си кредит на доверие, веейки знамето на децентрализацията. От техния парцел (вече повече от десетилетие) не се роди нищо кой знае какво по различно от спекула. А походът им за децентрализация се оказа компрометиран от обичайните проявления на недъзите на пазара и на най-обикновената човешка алчност. Всъщност поход е твърде силна дума.

В тази връзка наблюдавам с интерес фотографската общност, част от която видя в NFT отдавна лелеяна възможност да направи малко пари от изкуство в дигиталния свят. С цената на това да обижда интелигентността на (част от) публиката си. Разбирам подхлъзването, но все пак е тъжно.

Иначе (поне за да не бъде чак толкова минорен този текст)… след почти десетгодишен флирт с Fujifilm, пак снимам с Nikon (доколкото снимам изобщо, разбира се) и е голям кеф. За всичкото това време Fuji някак не се придвижиха в посоката, която се надявах, а междувременно Nikon започнаха Z-системата си съвсем начисто, с нов и широк байонет за обективи. През отминалите една-две години стана повече от ясно, че се хвърлят с всички сили в тази посока, което нямаше как да не ме спечели отново.

Надявам се да има как поне малко повече да попътуваме през идната година. И да има повече поводи за снимане. Че за по-мащабни мечти сякаш нито му е времето, а още по-малко мястото.

Наздраве!

Week 52

2021-12-31 Yovko Lambrev

Post Syndicated from Yovko Lambrev original https://yovko.net/week-52/

Week 52

Наздраве!

Week 52

2021-12-31 Yovko Lambrev

Post Syndicated from Yovko Lambrev original https://yovko.net/week-52/

Week 52

Наздраве!

Week 52

2021-12-31 Йовко Ламбрев

Post Syndicated from Йовко Ламбрев original https://yovko.net/week-52/

Week 52

Наздраве!

Week 52

2021-12-31 Йовко Ламбрев

Post Syndicated from Йовко Ламбрев original https://yovko.net/week-52/

Week 52

В политически план добрата новина е, че доживяхме финала на латиносериала Борисов. Това обаче още нищо не означава, докато не доживеем разглобяването на модела, който направи Борисов възможен (от инициатива „Глобална България“ насам).

От света на информационните технологии през годината по-скоро нямаше нещо кой знае какво за отбелязване. Интернет става все по-централизиран. Облаците също. А гравитацията и значението им огромни. Съпротивата срещу това е слаба и наистина трудна и ще става все по-зле, доколкото хората, които се вълнуват от моралната страна на технологичния прогрес са невидимо малцинство. Днес, сега… Няма по-критично време, в което трябва да се опазят и подпомагат малките в света на технологиите. Но тези, които не преследват ръст на всяка цена. Защото нямаме полза от нови гиганти.

Криптаджиите продължават да надуват балони, най-новите от които са все по-парадоксални (NFT, Web3 и прочие). „Бойте се от данайците, когато ви поднасят дарове.“ Та и криптаджиите пропиляха всичкия си кредит на доверие, веейки знамето на децентрализацията. От техния парцел (вече повече от десетилетие) не се роди нищо кой знае какво различно от спекула. А походът им за децентрализация се оказа компрометиран от обичайните проявления на недъзите на пазара и на най-обикновената човешка алчност.

В тази връзка наблюдавам с интерес фотографската общност, част от която видя в NFT отдавна лелеяна възможност да направи малко пари от изкуство в дигиталния свят. Разбирам подхлъзването, но все пак е тъжно.

Иначе (поне за да не бъде чак толкова минорен този текст)… след почти десетгодишен флирт с Fujifilm отново снимам с Nikon (доколкото снимам изобщо, разбира се) и е голям кеф. За всичкото това време Fuji някак не се придвижиха в посоката, която се надявах, а междувременно Nikon започнаха Z-системата си съвсем начисто, с нов и широк байонет за обективи. През отминалите една-две години стана повече от ясно, че се хвърлят с всички сили в тази посока, което нямаше как да не ме спечели отново.

Наздраве!

Update on Linux hibernation support when lockdown is enabled

2021-12-31

Post Syndicated from original https://mjg59.dreamwidth.org/58077.html

Some time back I wrote up a description of my proposed (and implemented) solution for making hibernation work under Linux even within the bounds of the integrity model. It’s been a while, so here’s an update.

The first is that localities just aren’t an option. It turns out that they’re optional in the spec, and TPMs are entirely permitted to say they don’t support them. The only time they’re likely to work is on platforms that support DRTM implementations like TXT. Most consumer hardware doesn’t fall into that category, so we don’t get to use that solution. Unfortunate, but, well.

The second is that I’d ignored an attack vector. If the kernel is configured to restrict access to PCR 23, then yes, an attacker is never able to modify PCR 23 to be in the same state it would be if hibernation were occurring and the key certification data will fail to validate. Unfortunately, an attacker could simply boot into an older kernel that didn’t implement the PCR 23 restriction, and could fake things up there (yes, this is getting a bit convoluted, but the entire point here is to make this impossible rather than just awkward). Once PCR 23 was in the correct state, they would then be able to write out a new swap image, boot into a new kernel that supported the secure hibernation solution, and have that resume successfully in the (incorrect) belief that the image was written out in a secure environment.

This felt like an awkward problem to fix. We need to be able to distinguish between the kernel having modified the PCRs and userland having modified the PCRs, and we need to be able to do this without modifying any kernels that have already been released[1]. The normal approach to determining whether an event occurred in a specific phase of the boot process is to “cap” the PCR – extend it with a known value that indicates a transition between stages of the boot process. Any events that occur before the cap event must have occurred in the previous stage of boot, and since the final PCR value depends on the order of measurements and not just the contents of those measurements, if a PCR is capped before userland runs, userland can’t fake the same PCR value afterwards. If Linux capped a PCR before userland started running, we’d be able to place a measurement there before the cap occurred and then prove that that extension occurred before userland had the opportunity to interfere. We could simply place a statement that the kernel supported the PCR 23 restrictions there, and we’d be fine.

Unfortunately Linux doesn’t currently do this, and adding support for doing so doesn’t fix the problem – if an attacker boots a kernel that doesn’t cap a PCR, they can just cap it themselves from userland. So, we’re faced with the same problem: booting an older kernel allows the system to be placed in an identical state to the current kernel, and a fake hibernation image can be written out. Solving this required a PCR that was being modified after kernel code was running, but before userland was started, even with existing kernels.

Thankfully, there is one! PCR 5 is defined as containing measurements related to boot management configuration and data. One of the measurements it contains is the result of the UEFI ExitBootServices() call. ExitBootServices() is called at the transition from the UEFI boot environment to the running OS, and the kernel contains code that executes before it. So, if we measure an assertion regarding whether or not we support restricted access to PCR 23 into PCR 5 before we call ExitBootServices(), this will prevent userspace from spoofing us (because userspace will only be able to extend PCR 5 after the firmware extended PCR 5 in response to ExitBootServices() being called). Obviously this depends on the firmware actually performing the PCR 5 extension when ExitBootServices() is called, but if firmware’s out of spec then I don’t think there’s any real expectation of it being secure enough for any of this to buy you anything anyway.

My current tree is here, but there’s a couple of things I want to do before submitting it, including ensuring that the key material is wiped from RAM after use (otherwise it could potentially be scraped out and used to generate another image afterwards) and, uh, actually making sure this works (I no longer have the machine I was previously using for testing, and switching my other dev machine over to TPM 2 firmware is proving troublesome, so I need to pull another machine out of the stack and reimage it).

[1] The linear nature of time makes feature development much more frustrating

comments

Formatting Meeting

2021-12-31

Post Syndicated from original https://xkcd.com/2562/

Neither group uses iso 8601 because the big-endian enthusiasts were all at the meeting 20 years ago.

What Ever Happened to 3 Mile Island? – 42 years later

2021-12-31 Curious Droid

Post Syndicated from Curious Droid original https://www.youtube.com/watch?v=xUyDjGyW2m0

2021-12-30 Suneel Joshi

Post Syndicated from Suneel Joshi original https://aws.amazon.com/blogs/devops/define-application-boundary-using-aws-resources-tags-in-amazon-devops-guru/

Amazon DevOps Guru is an ML powered service that makes it easy to improve an application’s operational performance and availability. By analyzing application metrics, logs, events and traces, DevOps Guru identifies behaviors that deviate from normal operating patterns and creates insights that you can use to improve your application.

At re:Invent 2021, we announced a new tagging feature in DevOps Guru. This feature allows you to organize resources into logical applications, using AWS resources tags so that you can have more control over how applications are defined. Well-defined applications enable DevOps Guru to group related anomalies together to better identify problems and to provide more meaningful recommendations. A tag is a label consisting of a user-defined key and a value. Previously, the coverage boundary consisted of an entire AWS account or specific resources defined by AWS CloudFormation stacks.

Getting Started

Define Resources to analyze using AWS resources tags

An AWS resource tag is a label that consists of a key and a value. A key-value pair can create useful grouping of resources into different applications. For DevOps Guru, you specify one tag key across all your applications. Resources with the same tag value are grouped together into a logical application. The tag key needs to be prefixed with the string “devops-guru-”. Note that the prefix string is not case sensitive. The tag value can be any value you define. The next section describes how you can use tag values to define coverage boundary for your applications.

You can add tags to your resources using the AWS service to which each resource belongs, or use the Tag Editor. To manage tags using your resource’s service, you can use the console, AWS CLI or SDK of the service.

Define Application boundary using AWS resources tag values

For DevOps Guru, we define an application as a group of instantiated AWS resources (Amazon EC2, AWS Lambda, Amazon RDS, etc.) that your workload is running on. You assign the same tag value to all resources that make up your application. DevOps Guru will analyze each resource separately, and will also look at metrics and events across all resources in your application to detect anomalies and generate insights. For example, see the diagram below.

You can have one tag key across all your applications. For each application, assign a different tag value. All resources that make up an application should have the same tag value.

App 1 consists of 2 different resources for a database application – an EC2 instance and a database instance. Assigning the same tag value of RDS to both of the resources. I have another serverless application in App 2, which has a Lambda function and a DynamoDB instance. I assign a different tag value of serverless-app-1 to both of the App 2 resources.

Example Test Scenario

I am going to create a test scenario with an application server running in an EC2 instance. The application server is connected to an Aurora MySQL-Compatible database instance. I will instrument my application to introduce a misbehaving SQL query to create a performance anomaly.

In my example below, I tagged my EC2 instance and database instance with the tag value of RDS. I am interested in detecting performance issues in my Database instance and I want DevOps Guru to provide recommendations to fix those issues.

Manage DevOpsGuru Analysis Coverage

Next, I define the coverage boundary in DevOps Guru Console. In the Settings options in navigation pane, I select Analyzed resources and choose Edit.

To define coverage boundary in the DevOps Guru Console, select the “Settings” option in navigation pane, select “Analyzed resources“ and choose Edit.

Next, I select the “devops-guru-applications” as tag key from the dropdown menu. I am going to select RDS as the tag value, since I am interested in looking at performance issues in my Amazon Aurora database instance.

In the “Edit analyzed resources” screen, choose your tag key in the “Tag key” dropdown menu. Next, press the radio button for choosing specific tag values and then select the tag values to define the coverage boundary of your application.

Filter insights by tags

Next, I created my test scenario. Once DevOps Guru generated an insight, I am able to filter the insights by tag key or tag values. To display insights for my database instance, I select “Affected applications” from the search menu bar on insights page as shown below:

Insights generated by DevOps Guru can be filtered based on the tag values. Select “Affected applications” in the search menu bar in insights page.

Next, I select “Affected applications” as RDS in the above dropdown menu. Below is the Insight overview screen that gets displayed.

The metrics section of the Insights page provides a summary of the Anomaly detected. It also displays a graphical representation of the time window when the anomaly was detected as well as the detailed metric the anomaly was based upon.

The insights generated by DevOps Guru for my Amazon Aurora instances are enabled by Amazon DevOps Guru for RDS, a new feature we announced at re:Invent 2021. It allows developers to easily detect, diagnose, and resolve performance and operational issues in Amazon Aurora. For more information on Amazon DevOps Guru for RDS, see a related news blog written by my colleague, Marcia Villalba.

The insight summary indicates that there is high DB load, ten times above baseline. DevOps Guru for RDS uses anomaly detection on the database load (DB load) performance metric to detect issues. DB load is measured in units of Average Active Sessions (AAS). DB load measures the level of activity in your database, making it a great metric to understand the health of your database.

If you continue scrolling on the DevOps Guru for RDS analysis page, you can discover the cause for the problem and some recommendations to fix it. DevOps Guru for RDS detected there was a high load of wait events, and one SQL query was found to require further investigation. You can even see the exact SQL query if you click on the SQL digest IDs. The insight’s analysis and recommendation section is full of information on how to investigate further and fix the issue.

The easy-to-understand recommendations made by DevOps Guru for RDS means that as a DevOps engineer, you do not need to rely on a database administrator (DBA) or use any third party tools.

DevOps Guru for RDS provides specific recommendations to fix the performance issues detected. In this example, specific wait events contributing to high DB load were identified and specific SQL query ID was identified as a major contributor

Conclusion

AWS resources tags give you one more way to specify the resource analysis coverage boundary, in addition to existing methods of an entire AWS account or specific AWS CloudFormation stacks. AWS tags allows you to better isolate the applications you want DevOps Guru to analyze. In this post, we used AWS tags to define the coverage boundary for a database application. We reduced unrelated and unnecessary resource coverage from our analysis, thereby controlling our resource analysis costs. Visit the DevOps Guru documentation to learn more about how to use tags to identify resources in your DevOps Guru applications.

About the author

Мрачни опасения

2021-12-30

Post Syndicated from original http://www.gatchev.info/blog/?p=2406

Ситуацията в Украйна хич не ми харесва. Нещата, които стигат до мен иззад кулисите – още повече.

Възможно ли е просто да съм уплашен? Или да ме гони параноята? Разбира се. Но е възможно и да съм прав. А кое от двете е реалното – преценете си вие. Или, ако го покажат фактите, си направете изводи.

Малко скучна теория

Описанието почва доста отдалече – нещата в него са важни за разбирането на ситуацията. И е поразводнено – пиша го много набързо, за което поднасям извинения.

Всяка икономическа система си има два етапа на развитие – екстензивен и интензивен. Примерно съвременната индустриално-пазарна икономика отначало заменя мотиките с трактори, прави излишните селяни на работници, разорава целините и т.н. Екстензивен растеж – усвояват се налични крайни, изчерпваеми ресурси… Когато се изчерпят – колкото може селяни са направени на работници, колкото има целини са разорани и т.н. – започва интензивният етап. На който вече за да намериш работници за нов завод трябва да закриеш стар (не-заети с високопроизводителен труд вече няма), за да построиш нова сграда трябва да разрушиш стара (свободно място вече няма), и т.н.

Защо е важно това? Авторитарните и демократичните системи имат различни силни и слаби страни. Много опростено: авторитарните са по-силни на екстензивния етап, заради централизираната си координация. Пуснете на два еднакви девствени острова авторитарна и демократична системи – авторитарната ще усвои изцяло своя остров първа. Но пък демократичните системи са по-силни на интензивния етап, при тях съпротивата срещу замяната на старото с ново във всякакви отношения се преодолява по-лесно.

Къде е важната разлика? Екстензивният етап е фон Нойманов като характеристика на развитие, бързо изчерпва наличните ресурси. Затова и трае десетки пъти по-малко от интензивния. Съответно в началото на икономическата система авторитарните икономики дръпват рязко и изпреварват пазарните. Но стигнат ли до интензивния етап, влизат в стагнация. Съответно демократичните постепенно ги настигат, задминават и надконкурирват до разпад. Примерно през 1930-те СССР расте с двуцифрени темпове, докато западните икономики ги тресат кризи и депресии. Или пък Германия след катастрофата от Първата световна прави невиждана експлозия на развитие след централизирането на икономиката си под Хитлер, за няма десет години задминава победителите си Англия и Франция… Но малко след средата на 1930-те екстензивният етап за западните икономики приключва и започват да се съвземат. А пък през 1950-те етапът приключва и за СССР (и сателитите му), и в тях започва стагнация. Как свършва това надпреварване знаем.

(Ако питате къде е в картинката Хитлер – идеологията му го притисна към военна експанзия преди да успее да го притисне икономическия преход. Ако беше лидер с мирна визия, до още година-две щеше да приключи екстензивния етап на развитие, и до още максимум 2-3 години след това нуждата от военна експанзия пак щеше да е дошла, с брутална сила заради бързия растеж. А и неговият тип икономика е доста авторитарен, близо до китайския модел. В такива тя притиска много по-тежко, отколкото би притиснала примерно САЩ или някоя западноевропейска страна… Така че Втората световна беше въпрос не на „дали“, а на „кога“.)

От теорията – към практиката

В момента Русия и Китай са на етапа на преход от екстензивен към интензивен растеж. При Русия този преход е доста замазан и постепенен. Започна още преди към 15 години, на базата на оставеното от СССР наследство, и вероятно ще продължава поне още 20-30. Съответно спадането на растежа и стагнацията са разточени върху няколко десетилетия – руските управници не са твърде притиснати от ситуацията. Китай обаче тръгва от де факто феодализъм, и западните фирми и технологии и безмилостната експлоатация на китаеца съградиха индустриална икономика в него с темпове почти като на Хитлерова Германия. За трийсет години – от дървените мотики до първа по сравними цени икономика на света. Няма как преходът да не е рязък и брутален, със силна стагнация след него.

Какъв е резултатът? Дойде ли стагнацията, авторитарната система реагира според ситуацията си. Ако стагнацията е мека и постепенна, околният свят е тежко въоръжен с атомно оръжие и лидерите са хора без много мечти и амбиции извън техния си санджак, ще си кротуват и ще се радват на султанатите си. Ако обаче стагнацията е рязка, околният свят е слаб и разделен, и лидерите са с амбиции да го тъпчат, имат чудесен вариант – военна експанзия. Хем обявяват военни положения и разстрелват и най-дребното несъгласие в страните си, хем прибавят лебенсраум.

Защото са зли психопати ли го правят? Психопатите са със силно еволюционно предимство в авторитарната система, тя винаги издига на върха си такива. Но по-страшното е, че освен психопата на върха тя издига и психопати и под него, които дебнат да заемат мястото му на всяка цена, дори с риск за живота им. Така че този на върха не може да си позволи никаква слабост в управлението на държавата, ще му коства поста, а с него и главата. Ако е мухльо, сложен на върха като компромис, може и да го пратят да председателства някой забутан колхоз, но свален силен лидер не могат да си позволят да го оставят жив, винаги ще е твърде опасен. Това е един от структурните проблеми на авторитарната система – няма механизъм за мирно пенсиониране на силен лидер.

(Жокер: нито Путин, нито Кси са компромисни мухльовци.)

Ето затова мине-не мине, войските на Русия нагазват където е по-беззащитно и късат по някое парче, да поддържат широка опора за Фюрера сред „патриотизираната“ тълпа. Кога в Молдова, кога в Грузия, кога в Украйна… Путин не е кръволок, би бил щастлив да минава без това. Или поне да спазва подписа си под гаранцията, че ще пази териториалната цялост на Украйна, ако тя се откаже от ядреното оръжие. Само че би означавало сам да влезе в ковчега…

Проблемите на Путин са проблеми на Кси на десета степен. Ако има около някой трон по-безмилостни главорези от тези около руския, това е китайският. И Китай вече влиза в интензивния етап с трясък. Все още рапортува официално годишен растеж от 5-6-7%, но и това е доста надолу от обичайните за последните десетилетия 10-15%. А косвените данни показват, че е лъжа и че реалният растеж вече е не повече от 2-3%. И вероятно и ще продължава да спада… Така че Кси вече е изправен пред проблема „военна експанзия или смърт“.

Съотборници или противници?

В момента Путин изглежда големият проблем и страшният агресор, но не е. Русия временно е сравнително стабилизирана, той не е в остра нужда от външна агресия. Кси обаче е. И, за разлика от Хитлер, той е не маниакален идеолог, а наследник на 5000 години традиция на манипулиране на околните да се избиват едни други, за да печели Китай. За него Русия е просто средство, с което да отвлече войските на „врага“ (НАТО и САЩ) по-далеч от Тайван, или където другаде Кси реши да атакува.

Какво прави Кси? Съюз с Русия. Срещу мръсния империализъм, който ги обгражда, въоръжава съседните им страни… и абе изобщо, не ще да се предаде доброволно и да признае превъзходството на арийската раса. Малко учения, съвместни действия, един-два тайни договора. И преди към година и половина – договореност как да действат заедно, по взаимна изгода.

Путин също е играч от класа. Хем е щастлив от тази договореност, хем не много. Затова играе с Китай, но и си прави своите сметки.

Защо е щастлив? Ако около Китай има наистина лакома хапка, това е Русия. Огромна територия, огромни ресурси, слабо защитени срещу такъв като Китай. Русия няма и 150 милиона население – Китай може да мобилизира 300 милиона армия. И има индустрията да я снабдява с оръжия, над 20 пъти руската. Да, Русия има купища атомно оръжие и може за минути да анихилира 200-300 милиона китайци. От което другарят Кси ще си го премести в другия крачол. В Китай има точно един китаец, чийто живот струва за Кси повече от нищо, и това е той самият. Десет години по-късно Китай ще е една трета от земното кълбо, ако не и повече, а Кси – най-великият император в историята му… И Путин разбира този начин на мислене много добре, твърде сходен е с неговия собствен. Така че е много щастлив, че подобно развитие се отлага.

А защо Путин не е много щастлив? Защото знае и че и Кси разбира какво разбира той, и че отлагането няма да е безплатно. Че ще се наложи да участва в някои китайски планове. И че дори да превземат заедно с Кси целия свят, след това Китай пак ще се обърне срещу Русия – и тя няма да може да го спре. Така че се налага да си прави плановете много внимателно – иначе падането на Русия ще е не „дали“, а „кога“.

Генералната репетиция

През януари миналата година планът влезе в действие. Русия се заподготвя за атака срещу Украйна, Китай – срещу Тайван. Сметката беше да ангажират САЩ едновременно в две войни на двата противоположни края на света. Разпокъсани така, САЩ вероятно ще изгубят и двете. А откажат ли се да участват, външнополитическата им катастрофа ще е равностойна на двойно военно поражение. И в двата случая целият свят ще премине на страната на Русия и Китай. На цената, естествено, на безпрекословно подчинение.

Само че Джо Байдън се оказа лисица, която разбира този начин на мислене и знае как да му противостои ефективно. Моментално разбра, че слабото звено в картинката е Путин, и оказа върху него адекватния вид натиск. Обясни му, че няма да прати нито един войник в Украйна, а ще концентрира цялата си армия в Тайван, за да разгроми там китайците – разположи ли я всичката на враждебна за тях територия, ще успее. А Украйна ще зарине с оръжия и пари. И евросъюзниците от НАТО с удоволствие ще помогнат – те са военни джуждета, но не и икономически или индустриални. Бъдат ли така оборудвани, украинците ще поотстъпят, но вероятно ще успеят да задавят руската армия до окопна война, и няма да подписват примирия на тези позиции. А окопната война е война на изтощение, печели я по-силната икономика. С икономиките на САЩ и Русия зад Украйна и разгромен в Тайван Китай, Русия ще изгуби тази война. А Путин – вероятно главата си… И когато към тоягата се прибави и морков – обещание за международна среща, на която Путин да може да блесне – Путин предаде Кси. Спаси си главата.

(Байдън би трябвало да не е загадка за всеки мислещ българин. Ние вече сме имали управник, който изглеждаше идиот, но 35 години седя на власт сред също жадни за власт психопати и нищо не можеше да го помръдне. Чак докато не направи истинската глупост – да се опъне на промени, наредени от Москва… И Байдън винаги е трупал издънка върху издънка – правел е идиотски лапсуси, изглеждал е палячо и като почне да говори, е забравял да спре. Само че вече почти 50 години е непоклатим конгресмен и сенатор в Сената на САЩ. Също място, където недостатъчно акълните не могат и да припарят, камо ли да се задържат. Не е редно мислещ българин да не си зададе въпроса идиот ли е всъщност, или…)

Само че ако Путин беше изкаран от войната с голи обещания, Китай беше изкаран без дори да му се обърне капка видимо внимание. Падна по лице с трясък, без дори да са го погледнали накриво. Дипломатите по света се подрискаха от смях, китайският авторитет олекна осезаемо, вместо да натежи. Познайте дали това хареса на Кси. Да, не беше достатъчно, за да го свали от трона (доколкото знаем – пословично е как си приличат китайците…), но няма и как да го е направило щастлив.

Началото на пиесата

Какво е станало между Русия и Китай през пролетта и началото на лятото на 2021, мога само да се досещам. Май е било по-тайно от повечето дипломатически договорки… Но резултатът започна да се вижда още в началото на лятото. Русия продължи да доставя на ЕС договорените количества газ, но нищо повече. А част от потреблението на руски газ в ЕС винаги е било пряко купуване на борсата… И към началото на зимата всички газохранилища в ЕС, които разчитат на руски газ, се оказаха на практика празни. А ЕС политиците решиха, че руснаците просто ще се опитват да качват цената на газа и да натискат за Северен поток – 2. Къде им беше акълът, та не мислиха за военни развития дори след януарската криза, не знам. Европолитиците често са идиоти в това отношение, историята го доказва.

В тази ситуация наглед Путин е агресивен самодържец, но на практика е притиснат в ъгъла. И Западът е, който може да му осигури накъде да се измъкне. Осигури ли му, той ще се измъкне, не е глупав… Проблемът е, че Западът е глупав. Там руско-китайският начин на мислене е познат и разбираем за буквално единични политици, особено в САЩ…

Сега сме в същата ситуация като през януари, но този път много по-сериозна. От видимото: Русия спря доставките на газ за ЕС през украинските газопроводи. Турция беше изкарана от руската орбита и почна да доставя оръжие на Украйна – не ща да мисля какъв натиск е бил, за да огъне Ердоган. Натовски самолети разтоварват в Украйна оръжие и военни инструктори с бесни темпове и правят разузнавателни полети над Източна Украйна – преди първото беше в много по-скромни обеми, а второто изобщо го нямаше. Украйна обяви резервистки списъци за всички мъже и жени под 60 години – както високата възраст, така и ангажирането на жените е без аналог в историята ѝ. Швеция обяви повишена бойна готовност за армията си, и се готви да обяви готовност за евакуация на градовете и мобилизация на населението… Има и още много неща, и всичките ги нямаше при предишната криза. И говорят за същото – този път войната ще е трудна за избягване.

Новостите от последния момент

Планът за преговори беше за 10 януари за телефонен разговор между Путин и Байдън, а на 12 – за преговори между НАТО и Русия. Но от Белия дом днес изнесоха, че Путин е поискал спешен разговор с Байдън тази вечер, в 22:30 българско време… Кой и с какво може да накара Путин да си промени рязко плановете до степен да се моли на Байдън за спешен разговор? Точно един човек – Кси. И с нищо по-малко от директна заплаха или за война с Русия, или за живота на Путин. Добра демонстрация кой от двамата в каква позиция е в техния съюз.

А също и колко сериозно е ангажиран Китай с идеята за война срещу Запада. Или по-точно за война на Русия срещу Запада, за да срещне по-малко съпротива в Тайван. Колко здраво ще бъде притисната Русия да стигне на всяка цена до война с НАТО, и по възможност директно със САЩ… Аз лично смятам да следя изказванията на Белия дом след разговора много внимателно. (Кремъл не вярвам да даде информация по въпроса.)

Възможно ли е избягването на войната?

Ако Западът е наистина адекватен, ще търси как да даде на Путин изход от ъгъла. Да, в противен случай дори при успешен руски блицкриг в Украйна може буквално да срине руската икономика, със съответните последствия за Путин. Но този път натискът на Китай вероятно е също на живот и смърт. Знаят отлично руския начин на мислене (същия като техния), имат силни икономически връзки с много руски олигарси (главорезите под Путин), вече веднъж са се парили от руска „измяна“ – с гаранция са се погрижили да няма място за мърдане. Така че този път въпросът е дали Кси ще надманеврира Путин, или Путин (с помощта на Запада) ще надманеврира Кси. Колкото и да е парадоксално, техният съюз всъщност е надлъгване между тях двамата. И именно то е централното, от което зависи сега положението в света.

Какво следва?

Путин ще бави нещата колкото може да изтърпи Китай, за да даде на Запада възможност да му даде изход от ъгъла. Но пък Китай ще притиска Путин да бърза колкото се може повече, именно за да не даде на Запада възможност да даде на Путин изход. И очевидно има лостовете да притисне Путин до смърт… Така че нещата нищо чудно да се развият по-бързо, отколкото очакваме. А и да стигнат по-далече – може би много по-далече.

Ако Путин получи изход от ъгъла, Украйна ще се спаси. (Този път. Следващият може да е и много скоро – Китай няма да се откаже от военната експанзия, и успехът му в нея зависи от помощта на Русия. Така че дори този път да се мине с мир…) Ако (май по-скоро когато) не го получи, ще нападне Украйна. Кси ще го подкрепя „прикрито“ икономически (ако се наложи – вероятно и военно) и ще следи развитието. Успее ли Русия да прегази Украйна, Кси ще натисне Путин да продължи и към източноевропейските членки на НАТО, за да ангажира САЩ там, и вероятно ще успее. Путин пък вероятно ще поиска първо Китай да нападне Тайван, за да няма възможност САЩ да анихилират руската армия по бързата процедура, преди военната сила да им е потрябвала извън Европа. Може би също ще успее – руската армия има няколко много боеспособни единици, но масата ѝ е пушечно месо. Бъдат ли унищожени боеспособните единици, Русия може да се окаже неспособна да спре натовските армии. А те вероятно ще са амбицирани да се докажат след потенциална загуба на САЩ в Тайван, и ще се опитат да прегазят останалата без ресурси за съпротива Русия. Стигне ли се дотам, Путин ще си изгуби главата още в хода на войната. Съответно при този вариант той може дори официално да смени страните и да се съюзи със Запада срещу Китай – и Кси знае това. Така че има изгода да му помогне, като се ангажира в Тайван преди или едновременно с нападението на Русия срещу НАТО, и да го подкрепя масивно в Украйна и в Европа.

Как ще протече войната в Украйна? Основният удар ще е срещу източните и южни области, да подсигури на Русия дори при по-нататъшно задавяне до окопна война сухопътна граница с Крим и Приднестровието и да откъсне Украйна от Черно море. Най-вероятно ще бъдат бързо прегазени – украинската армия знае, че няма да може да спре първи удар там, ще съсредоточи основните си сили да отбранява Киев. Успее ли да прегази бързо (за седмица-две) Източна и Южна Украйна, Русия ще продължи и срещу Западна. Дали ще смогне да я превземе, и колко бързо ще е, вече е под въпрос. Зависи например от адекватността на украинската армия и западните инструктори в нея, а това е голямо неизвестно.

Ако Русия успее да превземе сравнително бързо и Западна Украйна, натискът от Китай да продължи срещу Източна Европа ще е още по-силен от сегашния. Путин вероятно няма особено желание да го прави, завземането дори само на Източна и Южна Украйна ще е покрило целите му и нуждите на Русия и занапред, а да нападне НАТО е много сериозен риск. Може да се опита да мотае нещата на този етап, да се прави на задавен в Украйна, но надали номерът ще мине пред китайците за дълго. Те търсят да нападнат Тайван, а това със сигурност ще предизвика намесата там на САЩ. А стигне ли се дотам, ще има потенциал дори за варианта с пълна трета световна с ядрено ангажиране. И с разгръщане на войната из целия тихоокеански театър и цяла Европа. (Оттук и реакцията на шведите. Вероятно не са единствената европейска страна, която го прави, просто при тях е по-публично и се разбира.)

Как сме засегнати конкретно българите?

Ако войната се размине този път – вдигаме наздравица и се молим да е за по-дълго. (Но знаем и че надали ще е за повече от година-две, ако и толкова.) Ако обаче започне, търсим как да спасяваме от Русия и Украйна който може да бъде засегнат. Украинското правителство не е така пълно с руски агенти като българското, няма да предаде Украйна на Русия на тепсия. Които и в двете страни са здрави, ще са в риск да бъдат пратени на фронта. Които не са, ще са в риск заради трудностите и военната истерия.

Превземе ли Русия Украйна, там може да стане истински страшно и за напълно аполитичните. За да контролира превзетите територии с военна сила, Русия трябва да ангажира там значителна част от армията си, а тя ще ѝ трябва за в Европа. Затова ще предпочете да ги контролира както контролираше България след 9.9.1944. Ще събере отрепките на обществото, които за нищо не стават и мразят до смърт успелите и талантливите, ще ги въоръжи до зъби и ще им даде карт бланш да убиват, грабят и изнасилват колкото и когото щат, стига да държат положението под руски контрол. И отрепките ще убиват, грабят и изнасилват – най-вече тези, които притежават нещо, заемат някакви позиции, известни са или просто са ценност и стойност сами по себе си. Тези, които те мразят, откакто ги има. Не само местните Богдан Филовци и принц Кириловци, а и местните Райко Алексиевци и Сашо Сладуровци, може би даже още по-напред. Всеки, който не е готов да лиже задника на довчерашния сводник, джебчия, наемен убиец, мафиот…

И това е само началото. Русия няма да може да се противопостави на натиска на Китай да започне война с НАТО, за да ангажира войските му в Европа, далеч от Тайван. В такива ситуации кой плод късат най-напред? Който виси най-ниско към берача. А кой в Европа виси най-ниско към Русия?

И как тя ще задържи под контрол България, след като я превземе? Китайският натиск няма да спре – армията пак ще ѝ трябва, за срещу Западна Европа…

Колко е шансът да се стигне до най-черните варианти? Много ми се иска да е малък, но може и да не е. Затова и пиша този запис – предупреденият е въоръжен. Ако Русия нападне Украйна реално, е важно ситуацията в Тайван да се държи под око. Намеси ли се Китай там, няма да е чудно на България да ѝ остава до руска атака не повече от седмица-две след допрегазването на Украйна. И да е в опасност не само Черноморието, а цяла България.

Как би изглеждала руската атака? Съмнявам се да е с бомбардировки и десант. Правителството ни в момента е гъчкано с руски агенти. Министърът на отбраната се доказа публично и пред НАТО като такъв. Така че най-много Русия просто да пусне в центъра на София десетина парашутисти, които да арестуват няколко най-важни хора и да сложат на тяхно място своите мекерета. Армията ни най-вероятно ще е под заповед са неоказване на никаква съпротива и безпрекословно подчинение на руската, под страх от смъртно наказание… А може и до това да не се стигне – просто някои „отечественофронтовци“ ще вземат властта, вероятно със също толкова смешно количество сила, и ще обявят излизане от НАТО и официален съюз с Русия.

Какво ще последва – този филм вече сме го гледали преди няма и 80 години. И подозирам, че в епохата на съвременните комуникации ще стане доста по-бързо.

С една важна добавка – този път руснаците вероятно ще искат да осигурят руско етническо мнозинство в България. Което значи, че над половината българи може да получат възможността да обикнат Сибир, чрез опознаването му. Примерно всеки, който е постигнал нещо, успял в нещо, станал известен, или дори просто не е любимец на най-долната категория отрепки тук…

Ще стане ли? Не зная. Колко е вероятността? Надявам се да не е много. Но ако Русия прегази цяла Украйна, и Китай нападне Тайван… чувствайте се предупредени.

Пък ако всичко това се окажат просто параноични страхове, аз ще съм най-щастлив.

This sensor is TWICE as good as the rest!? The BEST door and window sensor is from Aqara.

2021-12-30 The Hook Up

Post Syndicated from The Hook Up original https://www.youtube.com/watch?v=c4-8Y7jUCn0

[$] Zero-copy network transmission with io_uring

2021-12-30

Post Syndicated from original https://lwn.net/Articles/879724/rss

When the goal is to push bits over the network as fast as the hardware can
go, any overhead hurts. The cost of copying data to be transmitted
from user space into the kernel can be especially painful; it adds latency,
takes
valuable CPU time, and can be hard on cache performance. So it is
unsurprising that the developers working with io_uring, which is all about performance, have
turned their attention to zero-copy network transmission. This
patch set from Pavel Begunkov, now in its second revision, looks to be
significantly faster than the MSG_ZEROCOPY option supported by current
kernels.

Port Royal: The Earthquake that Destroyed the Infamous Pirate Den

2021-12-30 Geographics

Post Syndicated from Geographics original https://www.youtube.com/watch?v=xU6OlsLQwIQ

So… the minute hand shows progression — apparently we think of time in wildly different ways

2021-12-30 Technology Connextras

Post Syndicated from Technology Connextras original https://www.youtube.com/watch?v=NeopkvAP-ag

Security updates for Thursday

2021-12-30

Post Syndicated from original https://lwn.net/Articles/880039/rss

Security updates have been issued by Debian (advancecomp, apache-log4j2, postgis, spip, uw-imap, and xorg-server), Mageia (kernel and kernel-linus), Scientific Linux (log4j), and SUSE (kernel-firmware and mariadb).

How Belcorp decreased cost and improved reliability in its big data processing framework using Amazon EMR managed scaling

2021-12-29 Diego Benavides

Post Syndicated from Diego Benavides original https://aws.amazon.com/blogs/big-data/how-belcorp-decreased-cost-and-improved-reliability-in-its-big-data-processing-framework-using-amazon-emr-managed-scaling/

This is a guest post by Diego Benavides and Luis Bendezú, Senior Data Architects, Data Architecture Direction at Belcorp.

Belcorp is one of the main consumer packaged goods (CPG) companies providing cosmetics products in the region for more than 50 years, allocated to around 13 countries in North, Central, and South America (AMER). Born in Peru and with its own product factory in Colombia, Belcorp always stayed ahead of the curve and adapted its business model according to customer needs and strengthened its strategy with technological trends, providing each time a better customer experience. Focused on this, Belcorp began to implement its own data strategy encouraging the use of data for decision-making. Based on this strategy, the Belcorp data architecture team designed and implemented a data ecosystem allowing business and analytics teams to consume functional data that they use to generate hypotheses and insights that are materialized in better marketing strategies or novel products. This post aims to detail a series of continuous improvements carried out during 2021 in order to reduce the number of platform incidents reported at the end of 2020, optimize SLAs required by the business, and be more cost-efficient when using Amazon EMR, resulting in up to 30% savings for the company.

To stay ahead of the curve, stronger companies have built a data strategy that allows them to improve main business strategies, or even create new ones, using data as a main driver. As one of the main consumer packaged goods (CPG) companies in the region, Belcorp is not an exception—in recent years we have been working to implement data-driven decision-making.

We know that all good data strategy is aligned to business objectives and based on main business use cases. Currently, all our team efforts are focused on the final consumers, and almost all business initiatives are related to hyper-personalization, pricing, and customer engagement.

To support these initiatives, the data architecture department provides data services like data integration, only one source of truth, data governance and data quality frameworks, data availability, data accessibility, and optimized time to market, according to business requirements like other big companies. To provide minimal capabilities to support all these services, we needed a scalable, flexible, and cost-efficient data ecosystem. Belcorp started this adventure a couple of years ago using AWS services like Amazon Elastic Compute Cloud (Amazon EC2), AWS Lambda, AWS Fargate, Amazon EMR, Amazon DynamoDB, and Amazon Redshift, which currently feed our main analytical solutions with data.

As we were growing, we had to continually improve our architecture design and processing framework in regards to data volume and more complex data solution requirements. We also had to adopt quality and monitoring frameworks in order to guarantee data integrity, data quality, and service level agreements (SLAs). As you can expect, it’s not an easy task, and requires its own strategy. At the beginning of 2021 and due to critical incidents we were finding, operational stability was affected, directly impacting business outcomes. Billing was also impacted, due to more new complex workloads being included, which caused an unexpected increase in platform costs. In response, we decided to focus on three challenges:

Operational stability
Cost-efficiency
Service level agreements

This post details some action points we carried out during 2021 over Belcorp’s data processing framework based on Amazon EMR. We also discuss how these actions helped us face the challenges previously mentioned, and also provide economic savings to Belcorp, which was the data architecture team’s main contribution to the company.

Overview of solution

Belcorp’s data ecosystem is composed by seven key capability pillars (as shown in the following diagram) that define our architectural design and give us more or less technological flexible options. Our data platform can be classified as a part of the second generation of data platforms, as mentioned by Zhamak Dehghani in How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh. In fact, it has all the limitations and restrictions of a Lakehouse approach as mentioned in the paper Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics .

Belcorp’s data platform supports two main use cases. On one side, it provides data to be consumed using visualization tools, encouraging self-service. On the other side, it provides functional data to end-users, like data scientists or data analysts, through distributed data warehouses and object storage more suited to advanced analytical practices.

The following reference design explains the main two layers in charge of providing functional data for these use cases. The data processing layer is composed of two sub-layers. The first is Belcorp’s Data Lake Integrator, which is a built-in, in-house Python solution with a set of API REST services in charge of organizing all the data workloads and data stages inside the analytics repositories. It also works as a point of control to distribute resources to be allocated for each Amazon EMR Spark job. The processing sub-layer is mainly composed of the EMR cluster, which is in charge of orchestrating, tracking, and maintaining all the Spark jobs developed using a Scala framework.

For the persistent repository layer, we use Amazon Simple Storage Service (Amazon S3) object storage as a data repository for analytics workloads, where we have designed a set of data stages that have operational and functional purposes based on the reference architecture design. Discussing the repository design in more depth is out of scope for this post, but we must note that it covers all the common challenges related to data availability, data accessibility, data consistency, and data quality. In addition, it achieves all Belcorp’s needs required by its business model, despite all limitations and restrictions we inherit by the design previously mentioned.

We can now move our attention to the main purpose of this post.

As we mentioned, we experienced critical incidents (some of which existed before) and unexpected cost increases at the beginning of 2021, which motivated us to take action. The following table lists some of the main issues that attracted our attention.

Reported Incidents	Impact
Delay in Spark jobs on Amazon EMR	Core workloads take a long time
Delay in Amazon EMR nodes auto scaling	Workloads take a long time
Increase in Amazon EMR computational usage per node	Unexpected cost increase
Lost resource containers	Workloads process a huge data crash
Overestimated memory and CPUs	Unexpected cost increase

To face these issues, we decided to change strategies and started to analyze each issue in order to identify the cause. We defined two action lines based on three challenges that the leaders wanted us to work on. The following figure summarizes these lines and challenges.

The data lake architecture action line refers to all the architectural gaps and deprecated features that we determined as part of the main problems that were generating the incidents. The Spark development best practices action line is related to the developed Spark data solution that had been causing instability due to bad practices during the development lifecycle. Focusing on these action lines, our leaders defined three challenges in order to decrease the number of incidents and guarantee the quality of the service we provide: operational stability, cost-efficiency, and SLAs.

Based on these challenges, we defined three KPIs to measure the success of the project. Jira incidents allow us to validate that our changes are having a positive impact; billing per week shows the leaders that part of the changes we applied will gradually optimize cost; and runtime provides the business users with a better time to market.

Next, we defined the next steps and how to measure progress. Based on our monitoring framework, we determined that almost all incidents that arose were related to the data processing and persistent repository layers. Then we had to decide how to solve them. We could make reactive fixes in order to achieve operational stability and not have an impact on business, or we could change our usual way of working, analyze each issue, and provide a final solution to optimize our framework. As you can guess, we decided to change our way of working.

We performed a preliminary analysis to determine the main impacts and challenges. We then proposed the following actions and improvements based on our action lines:

Data lake architecture – We redesigned the EMR cluster; we’re now using core and task nodes
Spark development best practices – We optimized Spark parameters (RAM memory, cores, CPUs, and executor number)

In the next section, we explain in detail the actions and improvements proposed in order to achieve our goals.

Actions and improvements

As we mentioned in the previous section, the analysis made by the architecture team resulted in a list of actions and improvements that would help us face three challenges: operational stability, a cost-efficient data ecosystem, and SLAs.

Before going further, it’s a good time to provide more details about the Belcorp data processing framework. We built it based on Apache Spark using the Scala programming language. Our data processing framework is a set of scalable, parameterizable, and reusable Scala artifacts that provide development teams with a powerful tool to implement complex data pipelines, achieving the most complex business requirements using Apache Spark technology. Through the Belcorp DevOps framework, we deploy each artifact to several non-production environments. Then we promote into production, where the EMR cluster launches all the routines using the Scala artifacts that reference each conceptual area inside the analytical platform. This part of the cycle provides the teams with some degree of flexibility and agility. However, we forgot, for a moment, the quality of the software we were developing using Apache Spark technology.

In this section, we dive into the actions and improvements we applied in order to optimize the Belcorp data processing framework and improve the architecture.

Redesigning the EMR cluster

The current design and implementation of the Belcorp data lake is not the first version. We’re currently in version 2.0, and from the beginning of the first implementation until now, we’ve tried different EMR cluster designs to implement the data processing layer. Initially, we used a fixed cluster with four nodes (as shown in the following figure), but when the auto scaling capability was launched and Belcorp’s data workloads increased, we decided to move it there to optimize resource usage and costs. However, an auto scaled EMR cluster has different options too. You can choose between core and task nodes with a minimal and maximum number of each. In addition, you can select On-Demand or Spot Instances. You can also implement an optimized allocation strategy using EMR instance fleets to reduce the probability of Spot Instance loss. For more information about Amazon EMR resources allocation strategies, see Spark enhancements for elasticity and resiliency on Amazon EMR and Optimizing Amazon EMR for resilience and cost with capacity-optimized Spot Instances.

We tested all these capabilities, but we found some problems.

First, although AWS offers many capabilities and functionalities around Amazon EMR, if you don’t have some degree of knowledge about the technology that you want to use, you may encounter many issues as the use cases arise. As we mentioned, we decided to use the Apache Spark data processing engine through Amazon EMR as a part of Belcorp data ecosystem, but we faced many issues. Whenever an incident appeared, it motivated the data architect team in charge to fix it, as a part of the operational and support tasks. Almost all these reactive fixes were related to changing Amazon EMR configuration to try different alternatives in order to efficiently solve these incidents.

We figured out that almost all incidents were related to resource allocation, so we tested many configuration options such as instance types, increasing the number of nodes, customized rules for auto scaling, and fleet strategies. This last option was used to reduce node loss. At the end of 2020, we validated that an EMR cluster with automatic scaling enabled with a minimum capacity of three On-Demand core nodes 24/7 and the ability to scale up to 25 On-Demand core nodes provided us with a stable data processing platform. At the beginning of 2021, more complex Spark jobs were deployed as a part of the data processing routines inside the EMR cluster, causing operational instability again. In addition, the billing was increasing unexpectedly, which alerted leaders whose team needed to redesign the EMR cluster in order to keep healthy operational stability and optimize the costs.

We soon realized that it was possible to reduce up to 40% of the current billing using Spot Instances, instead of keeping all core nodes in On-Demand consumption. Another infrastructure optimization that we wanted to apply was to replace a number of core nodes with task nodes, because almost all Belcorp data workloads are memory-intensive and use Amazon S3 to read the source data and write the result dataset. The question here was how to do that without losing the benefits of the current design. To answer this question, we had the guidance of the AWS Account Team and our AWS Analytics and Big Data Specialist SA, in order to clarify questions about the following:

Apache Spark implementation in Amazon EMR
Core and task node best practices for production environments
Spot Instance behavior in Amazon EMR

We definitely recommend addressing these three main points before applying any changes because, according to our previous experience, making modifications in the dark can lead to costly and underperforming Amazon EMR implementation. With that in mind, we redesigned the EMR cluster to utilize EMR managed scaling, which automatically resizes your cluster for best performance at the lowest possible cost. We defined a maximum of 28 capacity units with three On-Demand core nodes always on (24/7) in order to support data workloads during the day. We then set an auto scaling limit of six On-Demand cores in order to provide minimal HDFS capabilities to support the remaining 22 task nodes composed of Spot Instances. This final configuration is based on advice from AWS experts that we have at least one core node to support six task nodes, keeping a 1:6 ratio. The following table summarizes our cluster design.

Cluster Scaling Policy	Amazon EMR Managed Scaling Enabled
Minimum node units (`MinimumCapacityUnits`)	3
Maximum node units (`a`)	28
On-demand limit (`MaximumOnDemandCapacityUnits`)	6
Maximum core nodes (`MaximumCoreCapacityUnits`)	6
Instance type	m4.10xlarge
Number of primary nodes	1
Primary node instance type	m4.4xlarge

The following figure illustrates our updated and current cluster design.

Tuning Spark parameters

As any good book about Apache Spark can tell you, Spark parameter tuning is the main topic you need to look into before deploying a Spark application in production.

Adjusting Spark parameters is the task of setting up the resources (CPUs, memory, and the number of executors) to each Spark application. In this post, we don’t focus on driver instance resources; we focus on the executors because that’s the main issue we found inside Belcorp’s implementation.

After we applied improvements around join operation and cache strategies in Spark application development, we realized that some of those applications were assigned with overestimated resources in the EMR cluster. That means Spark applications assigned resources, but only 30% of the resources were used. The following Ganglia report illustrates the overestimation of resource allocation for one Spark application job, which we captured during one of our tests.

A big consequence of this behavior was the massive deployment of EMR nodes that weren’t being properly utilized. That means that numerous nodes were provisioned because of the auto scaling feature required by a Spark application submit, but much of the resources of these nodes were kept free. We show a basic example of this later in this section.

With this evidence, we began to suspect that we needed to adjust the Spark parameters of some of our Spark applications.

As we mentioned in previous sections, as part of the Belcorp data ecosystem, we built a Data Pipelines Integrator, which has the main responsibility of maintaining centralized control of the runs of each Spark application. To do that, it uses a JSON file containing the Spark parameter configuration and performs each spark-submit using Livy service, as shown in the following example code:

'/usr/lib/spark/bin/spark-submit' '--class' 'LoadToFunctional' '--conf' 'spark.executor.instances=62' '--conf' 'spark.executor.memory=17g' '--conf' 'spark.yarn.maxAppAttempts=2' '--conf' 'spark.submit.deployMode=cluster' '--conf' 'spark.master=yarn' '--conf' 'spark.executor.cores=5' 's3://<bucket-name>/FunctionalLayer.jar' '--system' 'CM' '--country' 'PE' '--current_step' 'functional' '--attempts' '1' '--ingest_attributes' '{"FileFormat": "zip", "environment": "PRD", "request_origin": "datalake_integrator", "next_step": "load-redshift"}' '--fileFormat' 'zip' '--next_step' 'load-redshift'

This JSON file contains the Spark parameter configuration of each Spark application related to an internal system and country we submit to the EMR cluster. In the following example, CM is the name of the system and PE is the country code that the data comes from:

"systems" : {
  "CM" : {
    "PE" : { 
      "params" : {"executorCores": 15, "executorMemory": "45g", "numExecutors": 50 },
      "conf" : { "spark.sql.shuffle.partitions" :120 }
    }
}

The problem with this approach is that as we add more applications, the management of these configuration files becomes more complex. In addition, we had a lot of Spark applications set up with a default configuration that was defined a long time ago when workloads were less expensive. So, it was expected that some things would change. One example of a Spark application with uncalibrated parameters is shown in the following figure (we use four executor instances only for the example). In this example, we realized we were allocating executors with a lot of resources without following any of the Spark best practices. This was causing the provisioning of fat executors (using Spark slang) allocating each of those in at least one node. That means that if we define a Spark application to be submitted using 10 executors, we require at least 10 nodes of the cluster and use 10 nodes for only one run, which was very expensive for us.

When you deal with Spark parameter tuning challenges, it’s always a good idea to follow expert advice. Perhaps one of the most important pieces of advice is related to the number of executor cores you should use in one Spark application. Experts suggest that an executor should have up to four or five cores. We were familiar with this restriction because we formerly developed Spark applications in the Hadoop ecosystem because of Hadoop File Systems I/O restrictions. That is, if we have more cores configured for one executor, we perform more I/O operations in a single HDFS data node, and it’s well known that HDFS degrades due to high concurrency. This constraint isn’t a problem if we use Amazon S3 as storage, but the suggestion remains due to the overload of the JVM. Remember, while you have more operational tasks, like I/O operations, the JVM of each executor has more work to do, so the JVM is degraded.

With these facts and previous findings, we realized that for some of our Spark applications, we were using only 30% of the assigned resources. We needed to recalibrate the Spark job parameters in order to allocate only the best-suited resources and significantly reduce the overuse of EMR nodes. The following figure provides an example of the benefits of this improvement, where we can observe a 50% of node reduction based on our earlier configuration.

We used the following optimized parameters to optimize the Spark application related to the CM system:

"systems" : {
  "CM" : {
    "PE" : { 
      "params" : {"executorCores": 5, "executorMemory": "17g", "numExecutors": 62 },
      "conf" : { "spark.sql.shuffle.partitions" :120 }
    }
}

Results

In this post, we wanted to share the success story of our project to improve the Belcorp data ecosystem, based on two lines of actions and three challenges defined by leaders using AWS data technologies and in-house platforms.

We were clear about our objectives from the beginning based on the defined KPIs, so we’ve been able to validate that the number of JIRA incidents reported at the end of May 2021 had a notable reduction. The following figures shows a reduction of up to 75% in respect to previous months, highlighting March as a critical peak.

Based on this incident reduction, we figured out that almost all Spark job routines running in the EMR cluster benefitted from a runtime optimization, including the two most complex Spark jobs, with a reduction up to 60%, as shown in the following figure.

Perhaps the most important contribution of the improvements made by the team is directly related to the billing per week. For example, Amazon EMR redesigning, the join operation improvements, cache best practices applied, and Spark parameter tuning—all of these produced a notable reduction in the use of cluster resources. As we know, Amazon EMR calculates billing based on the time that the cluster nodes have been on, regardless of whether they do any work. So, when we optimized EMR cluster usage, we optimized the costs we were generating as well. As shown in the following figure, only in 2 months, between March and May, we achieved a billing reduction of up to 40%. We estimate that we will save up to 26% of the annual billing that would have been generated without the improvements.

Conclusion and next steps

The data architecture team is in charge of the Belcorp data ecosystem’s continuous improvements, and we’re always being challenged to achieve a best-in-class architecture, craft better architectural solution designs, optimize cost, and create the most automated, flexible, and scalable frameworks.

At the same time, we’re thinking about the future of this data ecosystem—how we can adapt to new business needs, generate new business models, and address current architectural gaps. We’re working now on the next generation of the Belcorp data platform, based on novel approaches like data products, data mesh, and lake houses. We believe these new approaches and concepts are going to help us to cover our current architectural gaps in the second generation of our data platform design. Additionally, it’s going to help us better organize the business and development teams in order to obtain greater agility during the development cycle. We’re thinking of data solutions as a data product, and providing teams with a set of technological components and automated frameworks they can use as building blocks.

Acknowledgments

We would like to thank our leaders, especially Jose Israel Rico, Corporate Data Architecture Director, and Venkat Gopalan, Chief Technology, Data and Digital Officer, who inspire us to be customer centric, insist on the highest standards, and support every technical decision based on a stronger knowledge of the state of the art.

About the Authors

Diego Benavides is the Senior Data Architect of Belcorp in charge of the design, implementation, and the continuous improvement of the Global and Corporate Data Ecosystem Architecture. He has experience working with big data and advanced analytics technologies across many industry areas like telecommunication, banking, and retail.

Luis Bendezú works as a Senior Data Engineer at Belcorp. He’s in charge of continuous improvements and implementing new data lake features using a number of AWS services. He also has experience as a software engineer, designing APIs, integrating many platforms, decoupling applications, and automating manual jobs.

Mar Ortiz is a bioengineer who works as a Solutions Architect Associate at AWS. She has experience working with cloud compute and diverse technologies like media, databases, compute, and distributed architecture design.

Raúl Hugo is an AWS Sr. Solutions Architect with more than 12 years of experience in LATAM financial companies and global telco companies as a SysAdmin, DevOps engineer, and cloud specialist.

assetfinder – Find Related Domains and Subdomains

2021-12-29

Post Syndicated from original https://www.darknet.org.uk/2021/12/assetfinder-find-related-domains-and-subdomains/?utm_source=rss&utm_medium=social&utm_campaign=darknetfeed

assetfinder is a Go-based tool to find related domains and subdomains that are potentially related to a given domain from a variety of sources including Facebook, ThreatCrowd, Virustotal and more.

assetfinder uses a variety of sources including those in the infosec space and social networks which can give relevant info:

crt.sh
certspotter
hackertarget
threatcrowd
wayback machine
dns.bufferover.run
facebook – Needs FB_APP_ID and FB_APP_SECRET environment variables set (https://developers.facebook.com/) and you need to be careful with your app’s rate limits
virustotal – Needs VT_API_KEY environment variable set (https://developers.virustotal.com/reference)
findsubdomains – Needs SPYSE_API_TOKEN environment variable set (the free version always gives the first response page, and you also get “25 unlimited requests”) — (https://spyse.com/apidocs)

Sources to be implemented:

http://api.passivetotal.org/api/docs/
https://community.riskiq.com/ (?)
https://riddler.io/
http://www.dnsdb.org/
https://certdb.com/api-documentation

Usage of assetfinder to Find Related Domains and Subdomains

The usage is very simple with only one option basically, to limit the search to subdomains only – by default it will scan for all associated domains and subdomains.

Read the rest of assetfinder – Find Related Domains and Subdomains now! Only available at Darknet.

Adapting to a 5G world

The talent is out there; it’s “just not evenly distributed.”

Cloud Simply Increases

Security is only getting more complicated. Companies must embrace zero trust

The corporate network (WAN) is dead. Long live the (Internet-based) corporate network

Matters of Privacy

Conclusion

#5: Disaster Recovery with AWS Managed Services, Part I: Single Region

#4: Exploring Data Transfer Costs for AWS Managed Databases

#3: Simplifying Multi-account CI/CD Deployments using AWS Proton

#2: Serverless Architecture for a Structured Data Mining Solution

#1: Introducing the new AWS Well-Architected Machine Learning Lens

Thank you!

Other blog posts in this series

Getting Started

Define Resources to analyze using AWS resources tags

Define Application boundary using AWS resources tag values

Example Test Scenario

Manage DevOpsGuru Analysis Coverage

Filter insights by tags

Conclusion

About the author

Малко скучна теория

От теорията – към практиката

Съотборници или противници?

Генералната репетиция

Началото на пиесата

Новостите от последния момент

Възможно ли е избягването на войната?

Какво следва?

Как сме засегнати конкретно българите?

Overview of solution

Actions and improvements

Redesigning the EMR cluster

Tuning Spark parameters

Results

Conclusion and next steps

Acknowledgments

About the Authors

The collective thoughts of the interwebz