Edits on platform eng pillar blog (#14198)

content/blog/platform-engineering-pillars-1/index.md

@@ -33,98 +33,98 @@ This series explores these key pillars of Platform Engineering, offering a pract
 
 <img align="right" style="margin: 15px;" width="300px" src="provisioning.png">
 
-### **Problem: Infrastructure Chaos and Bottlenecks**
+### **Problem: Infrastructure chaos and bottlenecks**
 
 Developers face many pain points with manual provisioning, which is why [Infrastructure as Code](https://www.pulumi.com/what-is/what-is-infrastructure-as-code/) has become so essential:
 
-* Inconsistent Environments: Dev, staging, and production drift apart. "Works on my machine" becomes everyone's excuse.
-* Slow Processes: Console clicking and waiting on ops creates bottlenecks. Developers wait days for basic infrastructure.
-* Configuration Drift: Manual configs lead to errors. Quick production fixes become undocumented mysteries that cause problems later.
-* Lack of Repeatability: Spinning up new environments or replicating existing ones is a complex, time-consuming, and often unreliable process.
+* **Inconsistent environments**: Dev, staging, and production drift apart. "Works on my machine" becomes everyone's excuse.
+* **Slow processes**: Console clicking and waiting on ops creates bottlenecks. Developers wait days for basic infrastructure.
+* **Configuration drift**: Manual configs lead to errors. Quick production fixes become undocumented mysteries that cause problems later.
+* **Lack of repeatability**: Spinning up new environments or replicating existing ones is a complex, time-consuming, and often unreliable process.
 
 That's why provisioning is the first pillar to master if you want to build a successful developer platform.
 
 <img align="left" style="margin: 15px;  margin-right:25px;" width="300px" src="self-service.png">
 
-### **Problem: Dependency Bottlenecks and Limited Developer Autonomy**
+### **Problem: Dependency bottlenecks and limited developer autonomy**
 
 <span style="margin-left:-15px">
 Even with automated provisioning, another challenge emerges - developers still struggle when tools are provided without considering usability.
 </span>
 
-* Hard to Find What You Need: Developers waste time hunting for the right infrastructure modules. They end up searching docs, bothering colleagues, or rebuilding something that already exists.
-* Too Much Complexity: Most developers aren't infrastructure experts. Learning all the options and parameters creates hesitation and mistakes.
-* Lack of Real Autonomy: Developers have the tools but not the confidence to use them. They still need approvals or fear breaking production.
-* Inconsistent Workflows: Teams create their own ways of using infrastructure, making collaboration harder.
+* **Hard to find what you need**: Developers waste time hunting for the right infrastructure modules. They end up searching docs, bothering colleagues, or rebuilding something that already exists.
+* **Too much complexity**: Most developers aren't infrastructure experts. Learning all the options and parameters creates hesitation and mistakes.
+* **Lack of real autonomy**: Developers have the tools but not the confidence to use them. They still need approvals or fear breaking production.
+* **Inconsistent workflows**: Teams create their own ways of using infrastructure, making collaboration harder.
 
-By implementing self-service infrastructure provising, you transform your platform from a centrally controlled system to a developer-centric environment. You unlock developer autonomy, accelerate development cycles, and free up operations teams to focus on higher-value activities.
+By implementing self-service infrastructure provisioning, you transform your platform from a centrally controlled system to a developer-centric environment. You unlock developer autonomy, accelerate development cycles, and free up operations teams to focus on higher-value activities.
 
 <img align="right" style="margin: 15px;" width="300px" src="developer-workflow.png">
 
-### **Problem: Inefficient and Fragmented Development Processes**
+### **Problem: Inefficient and fragmented development processes**
 
 Infrastructure is just one piece of the puzzle. Developers still face daily friction moving code to production.
 
 A typical developer's day is full of frustrations:
 
-* Inconsistent Local Environments: Variations in local setups, dependency conflicts, and operating system differences lead to debugging headaches and wasted time getting started.
-* Slow CI/CD Pipelines: Long builds, flaky tests, and mysterious pipeline configs block progress. Developers stare at progress bars instead of writing code.
-* Cumbersome Testing and Staging Setups: Provisioning environments for testing and staging can be a manual process. Environments may not accurately mirror production, leading to surprises and integration issues late in the development cycle.
-* Lack of Discoverability and Reusability: Nobody knows what code already exists, so everyone rebuilds it. Duplication becomes the norm.
-* Developer Toil and Context Switching: Developers spend more time on environment setup and troubleshooting than on writing features.
+* **Inconsistent local environments**: Variations in local setups, dependency conflicts, and operating system differences lead to debugging headaches and wasted time getting started.
+* **Slow CI/CD pipelines**: Long builds, flaky tests, and mysterious pipeline configs block progress. Developers stare at progress bars instead of writing code.
+* **Cumbersome testing and staging setups**: Provisioning environments for testing and staging can be a manual process. Environments may not accurately mirror production, leading to surprises and integration issues late in the development cycle.
+* **Lack of discoverability and reusability**: Nobody knows what code already exists, so everyone rebuilds it. Duplication becomes the norm.
+* **Developer toil and context switching**: Developers spend more time on environment setup and troubleshooting than on writing features.
 
 These inefficiencies add up, creating significant friction in the developer workflow. Developers spend more time wrestling with processes and less time focused on building and innovating. A Platform approach can help solve these challenges.
 
 <img align="left" style="margin: 15px;" width="300px" src="security.png">
 
-### **Problem: Security as a Bottleneck and Source of Friction**
+### **Problem: Security as a bottleneck and source of friction**
 
 Speed and efficiency matter, but security can't be compromised. Traditionally, security acts as a gate – a necessary hurdle before releasing software. Platform Engineering aims to transform security from a bottleneck into an enabler.
 
 For many developers, security feels like a roadblock, leading to common friction points:
 
-* Last-Minute Security: Checks happen at the end of development, causing costly rework when issues are found.
-* Restrictive Policies: Security rules feel arbitrary and unclear, slowing down deployments.
-* The "No" Department: Security teams are seen as blockers who enforce policies without offering solutions.
-* Speed vs. Security Mindset: Everyone believes you must choose between going fast and being secure.
-* Security is "Someone Else's Job": Developers think security is only the security team's responsibility.
+* **Last-minute security**: Checks happen at the end of development, causing costly rework when issues are found.
+* **Restrictive policies**: Security rules feel arbitrary and unclear, slowing down deployments.
+* **The "No" department**: Security teams are seen as blockers who enforce policies without offering solutions.
+* **Speed vs. security mindset**: Everyone believes you must choose between going fast and being secure.
+* **Security is "Someone else's job"**: Developers think security is only the security team's responsibility.
 
 This "security as a gate" approach not only slows things down but leads to workarounds as developers try to bypass security to meet deadlines.
 
 By integrating security into your platform, you transform security from a gatekeeper into a built-in feature of the development process. Security becomes an enabler of trust and speed, letting developers innovate with confidence.
 
 <img align="right" style="margin: 15px;" width="300px" src="observability.png">
 
-### **Problem: Data Overload Without Insights**
+### **Problem: Data overload without insights**
 
 Developers in modern cloud environments often find themselves in a paradox: they are drowning in data, yet starving for actionable information. Monitoring systems pump out metrics, logs, and traces, but finding what matters feels impossible. An ideal internal developer platform shifts the focus from data collection to actionable insights.
 
 Here's what developers typically experience:
 
-* Tool Sprawl: Teams use different tools for metrics, logs, and traces. Developers waste time jumping between dashboards and manually connecting the dots.
-* Alert Noise: Developers get bombarded with alerts lacking context or clear next steps. Important signals get buried in the noise.
-* Dashboard Overload: Existing dashboards overwhelm developers with granular metrics that are hard to connect to application behavior.
-* Reactive Debugging: Troubleshooting becomes a time-consuming fire drill. Developers spend hours sifting through logs to pinpoint issues.
-* Missing Proactive Insights: Observability is only used for firefighting. Developers lack insights to optimize performance or prevent issues before they affect users.
-* Disconnected from Production: Many developers feel blind to how their code actually runs in production, limiting their ability to improve it.
+* **Tool sprawl**: Teams use different tools for metrics, logs, and traces. Developers waste time jumping between dashboards and manually connecting the dots.
+* **Alert noise**: Developers get bombarded with alerts lacking context or clear next steps. Important signals get buried in the noise.
+* **Dashboard overload**: Existing dashboards overwhelm developers with granular metrics that are hard to connect to application behavior.
+* **Reactive debugging**: Troubleshooting becomes a time-consuming fire drill. Developers spend hours sifting through logs to pinpoint issues.
+* **Missing proactive insights**: Observability is only used for firefighting. Developers lack insights to optimize performance or prevent issues before they affect users.
+* **Disconnected from production**: Many developers feel blind to how their code actually runs in production, limiting their ability to improve it.
 
 This data flood without clear insights leaves developers reactive rather than proactive, hampering their ability to build reliable applications.
 
 By improving observability in your platform, you transform it from an operations function into a developer superpower. Developers gain the insights they need to build better applications with greater confidence, using AI to focus on what truly matters.
 
 <img align="left" style="margin: 15px;" width="300px" src="goverance.png">
 
-### **Problem: Balancing Autonomy with Control and Cost Efficiency**
+### **Problem: Balancing autonomy with control and cost efficiency**
 
 Empowering developers with self-service is essential, but unchecked autonomy leads to chaos. As platform adoption grows, organizations need to maintain control without creating bottlenecks. This is where Governance as Code becomes critical, establishing guardrails while preserving speed.
 
 Self-service creates new challenges:
 
-* Configuration Drift: In decentralized environments, infrastructure setups diverge from standards, creating security risks.
-* Cloud Cost Explosion: Without proper controls, self-service can lead to wasted resources and budget overruns. Teams over-provision or forget to clean up unused environments.
-* Compliance Headaches: Meeting regulatory requirements becomes harder when infrastructure is created in an uncontrolled way.
-* Audit Gaps: Without clear governance, tracking who created what and when becomes nearly impossible.
-* Manual Governance Slows Everything: If governance relies on approvals and tickets, it defeats the purpose of self-service.
+* **Configuration drift**: In decentralized environments, infrastructure setups diverge from standards, creating security risks.
+* **Cloud cost explosion**: Without proper controls, self-service can lead to wasted resources and budget overruns. Teams over-provision or forget to clean up unused environments.
+* **Compliance headaches**: Meeting regulatory requirements becomes harder when infrastructure is created in an uncontrolled way.
+* **Audit gaps**: Without clear governance, tracking who created what and when becomes nearly impossible.
+* **Manual governance slows everything**: If governance relies on approvals and tickets, it defeats the purpose of self-service.
 
 These challenges highlight the need for automated governance that scales with your platform, ensuring control without slowing developers down.
 
@@ -147,4 +147,4 @@ Ready to implement these principles in your organization? Check out "Platform En
 
 [**Get the Free Platform Engineering Ebook →**](https://info.pulumi.com/ebook/platform-engineering-iac-recommended-practices)
 
-And don't miss the next article in this series, where we'll explore Provisioning as the foundation of your developer platform journey.
+And don't miss the next article in this series, where we'll explore provisioning as the foundation of your developer platform journey.