CommPulse

Two weeks ago I posted my concerns about the long term viability of using Gemini in my automated content moderation app. We covered the option of alternate models there so please constrain this discussion to what appears to be sneaky policy settings to extract more revenue from Gemini users. When 2.5-flash-lite is deprecated my costs will be 16x on 3.1-flash-lite but actually it will be more than that because on the 3 series models you can't disable thinking nor specify temperature, top_p and top_k. Of those I only know a little about temperature which I have set set to 0.1 for my purposes. From 3.1 onward the best I will be able to do is specify a "LOW" thinking level which will burn at least some additional tokens and might break my app because having the model act deterministically is essential for content moderation purposes. Sure I could add additional system instructions to try and compensate for this loss of control but up go my input costs. Granted you can still specify maxOutputTokens but if that value is too low to account for the mandatory "thinking" the call will fail is that right? So we're going from a situation where you can tightly control the cost of each call to the LLM to one where you're at the mercy of the model. As I mentioned above I think this policy is sneaky which would be entirely consistent Google's opaque cloud billing and costs in general. Alternatively these changes are just where the rubber meets the road? submitted by /u/dougception to r/googlecloud [link] [comments]

I was in the process of creating an Azure SQL Managed Instance for our CIS dept (I work at a College). The cost estimate came out to $1,400/month - which is too much. Any way around that? submitted by /u/Real-Patriot-1128 to r/AZURE [link] [comments]

Last update August 14, 2026 at 8:29am PDT Description At 8/14/2026 7:35 AM PT, the Core Identity team became aware of an issue with email deliverability affecting customers in commercial cells. During this time, users may be experiencing intermittent issues receiving email from Okta. Our team is actively investigating this issue and is working to mitigate it. 8:39am PDT: Okta Engineering has determined that certain third-party providers were failing to receive emails from Okta. Our monitoring shows delivery rates are recovering to normal conditions and will continue to monitor until full resolution. Our next update will be in 30 minutes or sooner if additional information becomes available. 8:23am PDT: Okta Engineering is investigating and has determined that the incident is currently impacting email delivery to a subset of customers. During this time, customers may experience email delivery deferrals. We’ll provide an update in 30 minutes, or sooner if additional information becomes available. https://status.okta.com/#incident/a9CWR0000002FZG2A2 submitted by /u/BB03440 to r/sysadmin [link] [comments]

[ Removed by Reddit on account of violating the content policy . ] submitted by /u/cloudquell123 to r/FinOps [link] [comments]

submitted by /u/TutorHead7675 to r/FinOps [link] [comments]

When I talk to analytics leaders, the #1 thing they complain about is data debt. They assume their pipelines are fundamentally broken and that the only fix is a six-figure, multi-month overhaul of their cloud stack. Usually, that’s completely wrong. The problem isn't that data debt exists—every scaling company accumulates it as a natural byproduct of growth. The real problem is that their data debt is completely hidden in the dark . When data debt lives in the dark: Executives sit in 9:30 AM daily syncs arguing over spreadsheet semantics and metric definitions instead of making strategic decisions. Stakeholders treat the analytics team like a fast-food drive-thru, shouting isolated data requests into the microphone without context. Analysts waste 80% of their bandwidth acting as "data detectives" trying to trace broken C-suite CSV exports. At U&I Consulting , we don't promise to magically erase data debt overnight. Instead, we illuminate it . We bring hidden operational pipeline deficiencies into the light using Data Debt Diagnostics and formal Data Debt Tickets . When you quantify data debt and map it visually, it transforms from an invisible bottleneck into a clear, business-justified roadmap for the executive team. By combining this with Agile Ledger Architecture (ALA) , Medallion Pipelines (Bronze/Silver/Gold) , and KPI Shields , you protect team bandwidth and accelerate executive Time to Insight (TTI) . Stop trying to pretend data debt doesn't exist. Illuminate it, quantify it, and build an architecture that lets your business scale past it. 📖 Detailed in my book, "WHERE ARE THE INSIGHTS? The Blueprint for Agile Ledger Architecture" 🌐 Advisory & Diagnostics: uiconsulting.com submitted by /u/ui-consulting to r/FinOps [link] [comments]

Hello So i will be quick i want to ask some questions which are -------------------------------------------------------------------------- 1- I am a complete begineer who knows nothing so how can i learn finops like what things or tools or softwares would i need to learn communications and other skills or are tools enough -------------------------------------------------------------------------- 2- Is a FinOps a smart move right now for somone who doesn't have any experience with cloud but is willing to learn also are finding jobs preferably easy and how much can you expect 3- Is a fully remote job possible -------------------------------------------------------------------------- 4-Would it be a good option right now as compared to other options -------------------------------------------------------------------------- i had other questions which i wanted to ask but remember so will ask them at a later time submitted by /u/simply_complexiyo to r/FinOps [link] [comments]

Anybody here who feels AI SRE is a gimmick? I mean, what are we doing with this, honestly? Not gonna name names, but our observability platform ships one, and it takes 10–12 minutes to run an incident analysis and comes back with "hey, these are 2 things that are broken, and these are 5 probable causes." In the last three incidents, the causes it flagged were real issues acting up as bugs, but not related to the current incident at all. So I'm getting a faster RCA, just a wrong one. I raise a ticket and get misleading suggestions. Just to get an unbiased opinion, I tried out a few other names on the market: similar results. Happy to hear if anyone has had a different experience. submitted by /u/Less_Ad8195 to r/devops [link] [comments]

We're seeing issues with Ubuntu clients (22.04/24.04/26.04) failing to check in with Intune since thursday. Intune logs on the clients say "Failed to Check in with Intune. Failed to update device inventory. <some MS URL> Status Code 500". Some other logs also say 400 or 404. Latest version of intune-portal and microsoft-identity-broker installed. Downgrade did not help. Trying to enroll a new device will either: result in the device only landing in Entra, but not in Intune result in the device appearing in both Entra and Intune, but without any inventory data Entra shows "Ubuntu+26.04+LTS" as OS version, while Intune shows either nothing (blank) or "0.0.0.0", resulting in the device not picking up our compliance policy -> device will be not compliant -> user cant login to M365 apps. dsreg on the client shows that it correctly registered to Entra. Trying to trigger a sync or log in locally in the Intune portal app will immediately result in an error message ("Device could not be registered. There was an error, please try again"). Existing clients that are already enrolled also fail checkin and logon on the Intune portal app. But since they're still compliant users can still log in to M365 apps. There seems to be an issue going on at Microsoft's side. There's an open issue in the admin center (OP1459987), which sounds like it might be related giving the intune-portal app fails to update its device inventory. "Some admins may see outdated device inventory and update status information in the Microsoft 365 Apps admin center" submitted by /u/EpicSimon to r/sysadmin [link] [comments]

We have a currently CSP providing us licensing with a 10% discount over Microsoft's direct pricing, and thats fine by us. This relationship started out great with having a dedicated person we could ask licensing questions to that was fairly knowledgeable, so that was a nice perk when navigating the licenses available became a bit too much. Unfortunately we've began running into billing issues. These issues are taking far too long to work out. Our contacts have also become fairly unresponsive to our emails taking weeks to get back to us at times. This all prompts us to start looking around at options. Does anyone have any companies they currently have a good experience with? I don't really want to cold call, find a CSP that promises everything, and then puts us right back where we're at right now. We're just looking for licensing with a discount over going direct via Microsoft, this should be purely transactional so we need someone that makes it that easy. We are in the ~150 user range since I know that can make a large difference. Located west coast US. Thanks! submitted by /u/FIRE0118999881999119 to r/sysadmin [link] [comments]

submitted by /u/WancloudsInc to r/FinOps [link] [comments]

I'm sitting here scratching my head trying to figure this one out, I've went through our group policy settings multiple times and I can't find anything I might have configured that would cause this problem. new out of the box lenovo thinkpad laptop with 25H2 preload on it from factory. works great until it is joined to the domain, as soon as it joins the domain and rebooted, subsequent logins for any domain account or local account on the machine are having issues with not being able to run any apps other than edge or file explorer and on login it's giving an error stating that your system administrator has blocked the program. when I check the logs I'm seeing DistributedCOM errors with event id 10001 for Microsoft.AADBrokerPlugin, that appear to be related to windows security core background get token task classid webaccountprovider being unavailable. I'm not sure what the heck is going on here, but I need to get it fixed before it spreads to any of our existing windows 11 machines if it was caused by a malfunctioning windows update or something else. I'm about to blow the machine away and just load a clean install of 24h2 on it, but if anyone knows how to go about fixing this I'd like to try that first before I give up. this one is a replacement laptop for an employee and he can manage for a few days with his current laptop. my google-fu skiils haven't came up with anything that has worked thus far on it. I've reset it and it runs fine again until it is joined to our domain. I did notice when I ran systeminfo from a command prompt it is reporting that App Control for Business policy is enabled and app control for business user mode policy is set to audit. Looking on another machine that is still working fine, those two settings aren't activated. I tried local group policy to turn device guard off to see if that made a difference, but it didn't. submitted by /u/doctorevil30564 to r/sysadmin [link] [comments]

I currently handle SaaS & AI procurement for client orgs and want to add FinOps to my skillset. I'm non-technical, was in sales before procurement, and have a decent grasp on financial concepts having passed CFA level I (from a previous career path I thought I would go down but didn't). I have minimal cloud knowledge, should I start with AWS CCP to understand cloud fundamentals and so better understand the scenarios FOCP questions pose later, or start with the (as I understand it) less technical FOCP for a gentler learning curve? submitted by /u/BLWHpurple to r/FinOps [link] [comments]

https://preview.redd.it/4ceym8fdealh1.png?width=1672&format=png&auto=webp&s=839cc0b352c7b923cacd02b4386bc834f48dc47d A lot of compliance work isn't spent fixing security problems. It's spent finding the evidence . Screenshots. Spreadsheets. Configuration exports. Change logs. Emails between IT, security, risk, and compliance teams. Then the cycle starts again before the next audit. For Saudi enterprises working across frameworks such as NCA ECC, SAMA, PDPL, ISO 27001, PCI DSS, SOC 2, and others, the operational burden can become enormous. We broke down a five-step approach to making compliance more continuous: Map infrastructure to relevant frameworks continuously Generate evidence automatically Detect configuration drift early Unify visibility across multi-vendor environments Use AI for policy and gap analysis—not just reporting The interesting shift is from: "We need to prepare for the audit." to: "We should already be able to prove our compliance posture." That's where AI-driven continuous monitoring could have a significant impact. Full breakdown: How to Cut Compliance Audit Effort by 90%: A Practical Framework for Saudi Enterprises For anyone working in security or compliance: what currently consumes the most time during your audit preparation? #Compliance #Cybersecurity #NCAECC #SaudiArabia #AgenticAI #GRC submitted by /u/WancloudsInc to r/FinOps [link] [comments]

We run an internal self-service platform API. Individual humans wanting CLI/scripted access this is where I'm stuck . Currently we mint a static token, show it once in the UI, and the user keeps it. Two things bother me: Authority is frozen at creation. We store the list of accounts the token may touch. If the user later loses their admin role on one of those accounts, the token keeps working. The credential outlives the entitlement. Distribution is copy-paste. It ends up in .env files, shell history, occasionally a chat message. If you've done per-request authorization lookups, what did it cost you in latency and directory load? How long do you cache, and how do you handle the lookup failing fail open or fail closed? For humans needing programmatic access, has anyone made short-lived tokens work by exchanging an existing SSO session? Feels like the "right" answer but I haven't seen it described much outside cloud provider SDKs. Is there a simpler option I'm missing? Something like mTLS with per-user certs, or just accepting static tokens with a short expiry and good auditing? For anyone who went the secret-manager route: did rotation actually work invisibly, or did you get outages from clients that cached the value? submitted by /u/SmartWeb2711 to r/devops [link] [comments]

For transparency: I run a small UK hosting company, where WHMCS is our current billing/provisioning system. Last week I moved WHMCS 8.13.1 from a CloudLinux OS 9 box running Plesk, to a fresh Debian 13 box. Mostly as we had WHMCS on a shared host during our early days and now it needed its own space. Two things worth sharing if anyone else hits this: Debian 13 ships with PHP 8.4 by default whereas WHMCS wants 8.3 so you need to use the Ondrej Sury repository and not the base repository. ionCube loader has to be placed manually and the ini file renamed to 00-ioncube.ini rather than the default 20-ioncube.ini otherwise if it loads after OPcache, WHMCS breaks very unhelpfully with no clear errors pointing at the fault. Also worth flagging, we had stale absolute paths from the old server that lived in multiple places. We had some in configuration.php, the storage settings gui, and the tblconfiguration SQL table and also in config.php that took a while to track down. Also don't forget to redo the cron! Posting in the hopes it saves someone else an afternoon! submitted by /u/SortingYourHosting to r/sysadmin [link] [comments]

Overview of the GUI I wanted a real OpenShift lab on AWS to practise on, and I specifically wanted UPI — user-provisioned infrastructure — because it's the install method where nothing is hidden. You build the VPC, the load balancers and the DNS records, and the installer only takes over once that's all correctly in place. IPI hides most of that inside the installer binary; ROSA is managed. The problem with UPI is that doing it by hand is slow and easy to get wrong, and I couldn't find anything that automated the whole lifecycle for AWS. So I wrote one. **What it does** `cluster.yaml` is the only file you edit. Everything else — the Terraform variables, the Ansible variables, `install-config.yaml` — is generated from it. ``` ocplab deploy # terraform apply, wait for bootstrap, approve CSRs, finalize ocplab verify # ClusterVersion, node readiness, ClusterOperators ocplab cost # what's deployed right now, priced live ocplab repair # recreate a worker AWS reclaimed, approve its CSRs ocplab power off # graceful shutdown, as an alternative to destroying ocplab destroy # ordered teardown, including what the cluster made itself ``` Some things it handles that took me a while to get right: - **Version pinning.** One field pins the installer, the `oc` client and the RHCOS AMI together, cached locally. - **Spot instances** for compute and bootstrap, with a "minimal" profile that uses them. Not for the control plane — UPI has no ControlPlaneMachineSet, so a reclaimed master isn't replaced automatically. - **Cost visibility.** `ocplab cost` reads live AWS state and prices it, Spot at Spot rates, and it's power-state aware. - **A budget safety net.** AWS Budget with alerts, an automatic lockdown action, and a daily killswitch Lambda — managed outside Terraform so it survives a failed teardown. - **Optional capability trimming**, which cuts the container images pulled per deploy by about a third. - **Teardown that actually completes.** The ingress operator creates a load balancer, a security group and DNS records outside Terraform; the teardown removes them in the right order first. **The web UI** There's also a local browser UI (`ocplab web start`) if you'd rather not watch a 40-minute deploy in a terminal: a status dashboard, a `cluster.yaml` editor that validates before saving, and live output for every operation — including Terraform's resource-by-resource log and the installer's own log. It binds 127.0.0.1 only and runs the same commands as subprocesses, so there's no second implementation to keep in sync. **Scope** It's built for labs and PoCs, not production. Single AZ, single NAT gateway, no HA design beyond etcd's own quorum. It costs roughly $0.83–1.06/hour while it's up, so the intended flow is create, test, destroy the same day. Tested end to end against OpenShift 4.22.6 and 4.22.7. MIT licensed. https://github.com/LuixyToledo97/openshift-upi-aws Happy to answer questions, and issues are welcome if you try it and something doesn't work. submitted by /u/Financial_Spring636 to r/devops [link] [comments]

Cloud migration decisions are often evaluated through the lenses of security, availability, performance and cost. Portability is usually considered much later—sometimes only when an organisation needs to change providers, meet a new regulatory requirement or negotiate a major contract renewal. For KenyaBank, portability cannot be an afterthought. The bank is undertaking an 18-month programme to modernise a legacy core banking environment currently running on Oracle WebLogic and Oracle Database in its Westlands data centre. The target architecture introduces AWS services including Amazon Aurora PostgreSQL, Amazon DynamoDB, Amazon EventBridge, Amazon MSK, AWS IAM Identity Center, AWS Systems Manager and AWS CloudFormation. These services reduce infrastructure-management overhead and accelerate delivery. However, each managed service creates a different degree of dependency on AWS. The real question is therefore not: “Does the architecture contain vendor lock-in?” Almost every cloud architecture does. A more useful question is: “Is the lock-in understood, controlled and justified by the business value it provides?” This article audits five AWS-specific dependencies in KenyaBank’s target architecture, estimates the effort required to replace each one and assigns the overall architecture a portability score. KenyaBank is a Tier-1 Kenyan commercial bank serving approximately 4.2 million customers through 68 branches. Its existing environment includes: A monolithic Java EE core banking application Oracle WebLogic application servers A 3.8 TB Oracle 11g database A legacy internet-banking application Local teller servers in 68 branches An on-premises Microsoft Active Directory environment MPLS connectivity between branches and the Westlands data centre The target architecture uses the Strangler Fig pattern to extract capabilities from the monolith gradually. Internet banking will be containerised, the database will move towards Aurora PostgreSQL, and applications will increasingly communicate through events and managed messaging services. This gives KenyaBank a more scalable and resilient platform, but it also introduces several AWS-specific interfaces, data models and operational processes. //insert diag What is cloud vendor lock-in? Vendor lock-in occurs when moving an application, its data or its operational processes away from a provider would require significant time, cost or redesign. Lock-in is not a single condition. For this assessment, it is divided into three categories. API lock-in API lock-in occurs when application code depends directly on a provider-specific SDK, API, event format or service behaviour. For example, application code written around DynamoDB operations such as PutItem, Query and UpdateItem cannot simply be pointed at PostgreSQL. Data lock-in Data lock-in occurs when data is stored using a proprietary model or format that is difficult to reproduce in another platform. The challenge is not always exporting the raw records. It may involve translating partition keys, indexes, access patterns, relationships, transactions and consistency behaviour. Operational lock-in Operational lock-in occurs when an organisation’s deployment, identity, monitoring, patching or support processes depend on provider-specific tooling. The application may remain technically portable, but the operating model must be rebuilt before it can run elsewhere. The portability-scoring method Each dependency is assessed using five factors: Factor Question Application coupling How much code uses AWS-specific APIs? Data coupling How difficult is it to export and remodel the data? Infrastructure coupling Can the deployment definition run elsewhere? Operational coupling Must procedures and skills be rebuilt? Replacement availability Is there a mature portable alternative? The portability scale is defined as follows: Score Interpretation 1 Highly proprietary; substantial redesign required 2 Significant lock-in; migration would be difficult 3 Moderate lock-in; migration is feasible with planning 4 Mostly portable; limited provider-specific adjustments 5 Highly portable; based mainly on open standards Exit effort is expressed in engineering effort rather than a fixed monetary amount. A defensible financial estimate would require application size, event volume, table count, test coverage, staff rates and recovery requirements that are not provided in the scenario. The estimates assume a multidisciplinary team containing cloud, application, database, security and testing specialists. Dependency 1: Amazon DynamoDB How KenyaBank uses it The proposed architecture uses DynamoDB for session storage. This is attractive because DynamoDB provides managed scaling, high availability and low-latency key-value access without requiring KenyaBank to manage database servers. It is also the strongest source of lock-in in the assessed architecture. Nature of the lock-in Classification: API lock-in and data lock-in Portability score: 2 out of 5 Estimated exit effort: High — approximately 12–20 person-weeks DynamoDB applications are normally designed around: Partition and sort keys DynamoDB-specific query operations Global and local secondary indexes Conditional writes Time-to-live attributes DynamoDB Streams Provisioned or on-demand capacity behaviour AWS SDK request and response models Although DynamoDB tables are flexible, that flexibility does not make them automatically portable. The table design is typically based on application access patterns rather than relational normalisation. AWS supports full and incremental table exports to Amazon S3. These exports do not consume table read capacity, but the supported export formats are DynamoDB JSON and Amazon Ion—not a ready-made PostgreSQL schema. AWS documentation: DynamoDB export to S3 Exporting the records is therefore only the beginning. KenyaBank would still need to: Choose a replacement platform. Design the target schema. Translate DynamoDB-specific data types. Recreate indexes and expiration behaviour. Rewrite the repository or data-access layer. Migrate active sessions. Validate performance and consistency. Run the old and new stores in parallel. Cut over without invalidating customer sessions. Possible alternatives Potential alternatives include: Redis for short-lived customer sessions PostgreSQL for durable relational session records MongoDB for document-oriented access A Kubernetes-compatible Redis deployment A managed Redis service available from multiple providers For temporary session data, Redis would normally provide a more portable model than DynamoDB because its commands and client libraries are available across cloud and self-managed environments. Is the lock-in justified? Partly. DynamoDB is justified when KenyaBank needs very high scale, predictable low latency and minimal database administration. However, using it for ordinary session storage may create more coupling than necessary. The bank should first validate whether the expected session volume genuinely requires DynamoDB. If not, a portable Redis-based implementation may provide enough performance while reducing exit complexity. Recommended control KenyaBank should implement a repository interface between application code and DynamoDB: SessionRepository ├── DynamoDbSessionRepository ├── RedisSessionRepository └── PostgreSqlSessionRepository The business logic should depend on SessionRepository, not directly on the AWS SDK. This will not eliminate data migration, but it will reduce the amount of application code that must be rewritten. Dependency 2: Amazon EventBridge How KenyaBank uses it EventBridge can route business and operational events between loosely coupled application components. Rules match events and deliver them to configured targets. AWS describes an EventBridge event bus as a router that receives events and delivers them to one or more destinations. Rules use AWS-specific event patterns to inspect event metadata and detail fields. AWS documentation: EventBridge event patterns Nature of the lock-in Classification: API and operational lock-in Portability score: 2 out of 5 Estimated exit effort: Medium to high — approximately 8–14 person-weeks Coupling may develop in several places: The EventBridge event envelope PutEvents API calls AWS SDK integrations Event-pattern syntax Event bus policies Rule-to-target configuration Dead-letter queue configuration IAM permissions EventBridge Scheduler AWS-specific target integrations If business applications publish raw EventBridge events directly, a move to Kafka, Google Cloud Pub/Sub or another event platform will require changes to every producer. Consumers may also depend on fields such as source, detail-type, account, region and detail. Exit approach A controlled exit would require KenyaBank to: Inventory event buses, schemas, rules and targets. Define a provider-neutral event contract. Introduce an event-publishing abstraction. Translate existing events into the new format. Recreate routing and filtering rules. Implement retry and dead-letter handling. Run dual publishing during transition. reconcile missed or duplicated events. Retire EventBridge rules after validation. Is the lock-in justified? Yes, but only at the integration boundary. EventBridge is valuable for AWS service integration and operational automation. It can significantly reduce the code required to connect AWS services. For core banking domain events, however, the event itself should not be defined by EventBridge. KenyaBank should use a portable event specification such as CloudEvents and treat EventBridge as one possible transport. A portable business event might look like this: { "specversion": "1.0", "type": "ke.kenyabank.payment.completed.v1", "source": "/core-banking/payments", "id": "a03ac2f8-5e51-4c51-95d5-7714be667350", "time": "2026-07-29T09:30:00Z", "datacontenttype": "application/json", "data": { "paymentReference": "PAY-104582", "status": "COMPLETED" } } The same logical event could be transported through EventBridge, Amazon MSK or another cloud’s event service. Recommended control Standardise domain events using CloudEvents. Publish through an internal event interface. Keep AWS SDK calls inside adapters. Store event schemas in a provider-neutral repository. Avoid placing business rules exclusively in EventBridge rule definitions. Use EventBridge mainly for AWS-native operational events. Dependency 3: AWS CloudFormation How KenyaBank uses it CloudFormation defines AWS infrastructure as YAML or JSON templates. It gives KenyaBank repeatable deployments, change tracking and automated infrastructure management. However, CloudFormation templates use AWS-specific resource identifiers such as AWS::S3::Bucket and AWS::EC2::VPC. AWS documents these service-specific resource and property definitions in its CloudFormation resource reference. AWS documentation: CloudFormation resource syntax. Nature of the lock-in Classification: Operational lock-in Portability score: 2 out of 5 Estimated exit effort: Medium — approximately 8–16 person-weeks The deployed resources may use standard technologies, but the infrastructure definition cannot be applied directly to Azure, Google Cloud or an on-premises platform. Coupling increases when templates use: AWS-specific resource types Intrinsic functions such as Ref and Fn::GetAtt Nested stacks CloudFormation exports StackSets AWS-specific transforms Lambda-backed custom resources CloudFormation deployment pipelines Custom resources create additional coupling because they can invoke Lambda or SNS-based provisioning logic. AWS documentation: CloudFormation custom resources Exit approach Migrating from CloudFormation to Terraform or OpenTofu would involve: Inventorying all stacks and nested stacks. Mapping resources into the target tool. Rewriting parameters, outputs and dependencies. Importing existing infrastructure into the new state. Comparing both infrastructure definitions. Testing changes in a non-production account. Freezing CloudFormation changes during transition. Transferring resource ownership in controlled phases. Retiring stacks without deleting live resources. The main risk is not reproducing the YAML syntax. It is safely transferring control of already-running infrastructure without accidental replacement or deletion. Is the lock-in justified? Not for the long-term target state. CloudFormation is a capable option for AWS-only environments, but KenyaBank’s portability objective favours Terraform. The bank does not need to replace every existing template immediately. A phased six-month migration would be safer: Month 1: inventory and prioritisation Month 2: Terraform/OpenTofu standards and modules Months 3–4: non-production migration Month 5: production resource import Month 6: validation and CloudFormation retirement Recommended control Use Terraform or OpenTofu for new infrastructure. Create modules around architectural capabilities rather than individual resources. Keep environment values separate from reusable modules. Prohibit new CloudFormation custom resources during the transition. Apply deletion protection and lifecycle safeguards before importing production resources. Retain CloudFormation templates until rollback is no longer necessary. Dependency 4: AWS IAM Identity Center How KenyaBank uses it IAM Identity Center provides workforce access to multiple AWS accounts. KenyaBank intends to connect its existing Active Directory environment using SAML 2.0 and SCIM, with permission sets assigned to teams such as Banking Operations, Technology Operations, Development and Audit. This dependency is more nuanced than DynamoDB because its identity-federation interfaces use open standards. AWS IAM Identity Center supports SAML 2.0 for authentication and SCIM for user and group provisioning. An identity provider that implements these standards is expected to interoperate with IAM Identity Center. AWS documentation: SAML and SCIM federation Nature of the lock-in Classification: Primarily operational lock-in Portability score: 3 out of 5 Estimated exit effort: Medium — approximately 6–12 person-weeks The following elements are relatively portable: User identities retained in Active Directory SAML-based authentication SCIM-based provisioning Group membership General role-based access principles The AWS-specific components include: Permission sets AWS account assignments IAM policies AWS Organizations integration AWS account and organisational-unit mappings AWS-specific attributes and session controls Permission sets determine the level of access users and groups receive in AWS accounts. These permissions cannot be transferred directly to another cloud because other providers use different resource and policy models. AWS documentation: IAM Identity Center permission sets Exit approach Moving to another platform would require KenyaBank to: Retain Active Directory or another independent identity provider as the system of record. Integrate the target platform through SAML or OpenID Connect. Recreate user and group provisioning. Translate AWS permission sets into target-cloud roles. Replace IAM policy conditions. test privileged and emergency access. validate separation of duties. update access-review and audit procedures. Is the lock-in justified? Yes. The lock-in is acceptable because the authoritative identities remain outside AWS and federation relies on standard protocols. KenyaBank receives centralised access management across its AWS accounts without making AWS the permanent system of record for workforce identities. Recommended control Keep Active Directory as the authoritative identity store. Group users by business function, not by AWS service. Document every permission-set mapping. Export permission definitions into version control. Maintain a cloud-neutral access matrix. Test emergency access independently of normal federation. Avoid manually creating long-lived IAM users. This approach allows the bank to retain a portable identity-governance model even though cloud permissions remain provider-specific. Dependency 5: AWS Systems Manager How KenyaBank uses it KenyaBank intends to manage EC2 instances and 68 branch servers through AWS Systems Manager. Systems Manager hybrid activations allow on-premises servers, virtual machines and edge devices to register as managed nodes. Those machines then use the SSM Agent to communicate with AWS Systems Manager. AWS documentation: Systems Manager hybrid environments This gives the bank centralised inventory, patching, command execution, automation and audit history without requiring SSH access or bastion hosts. Nature of the lock-in Classification: Operational lock-in Portability score: 2 out of 5 Estimated exit effort: Medium to high — approximately 10–18 person-weeks The servers themselves remain portable, but the management processes become AWS-specific. Coupling includes: SSM Agent registration Hybrid activation codes IAM service roles Patch baselines Maintenance windows State Manager associations Run Command documents Automation runbooks Inventory and compliance reports Parameter Store integration CloudWatch and EventBridge automation The greater the number of SSM documents and automated remediation workflows, the greater the exit effort. Exit approach Potential replacements include: Ansible Automation Platform Red Hat Satellite Canonical Landscape Microsoft Configuration Manager Azure Arc Google Anthos Kubernetes-based management where appropriate Migration would require: Deploying the replacement agent or configuring agentless access. Recreating the server inventory. Translating patch baselines. Rebuilding maintenance schedules. Rewriting automation documents. Replacing IAM-based authorisation. Reconstructing audit and compliance reporting. Operating both platforms during transition. Deregistering the servers from Systems Manager Is the lock-in justified? Yes for the AWS estate; only partly for branch servers. Systems Manager is a strong fit for EC2 because it integrates naturally with IAM, CloudTrail, Patch Manager and AWS automation. Using it for all branch infrastructure provides consistency, but it makes the operational model AWS-dependent even when the servers are physically located outside AWS. For a regulated bank, that trade-off may still be justified if the centralised audit trail and reduced reliance on SSH materially improve security. Recommended control Write automation in scripts or Ansible where practical. Keep SSM documents thin and use them to invoke portable scripts. Store scripts in version control. Maintain an independent configuration-management database. Export compliance results into the bank’s central reporting platform. Document how servers would be managed if Systems Manager were unavailable. Test replacement management tooling on a small branch-server sample. Consolidated portability assessment Dependency Primary lock-in Portability Exit effort Is it justified? DynamoDB session store API and data 2/5 High Partly Amazon EventBridge API and operational 2/5 Medium–high Yes, at AWS integration boundaries AWS CloudFormation Operational 2/5 Medium No for the long-term target IAM Identity Center Operational 3/5 Medium Yes AWS Systems Manager Operational 2/5 Medium–high Yes, with controls [Screenshot placeholder: KenyaBank dependency and exit-effort matrix] Dependencies that improve portability Not every AWS-managed service creates the same level of risk. Two choices in the KenyaBank architecture make the environment more portable. Amazon MSK Amazon MSK runs open-source Apache Kafka and supports existing Kafka clients, tools and plugins. AWS documentation: What is Amazon MSK? If KenyaBank uses standard Kafka APIs, portable schemas and open-source connectors, producers and consumers can move to another Kafka distribution with relatively limited application changes. AWS-specific authentication, monitoring, replication and control-plane automation can still create operational coupling, but the data plane is substantially more portable than EventBridge. Estimated portability: 4 out of 5. Amazon Aurora PostgreSQL Aurora PostgreSQL is PostgreSQL-compatible and supports standard PostgreSQL tools. AWS documents migration options including pg_dump, pg_restore and AWS DMS. AWS documentation: Migrating Aurora PostgreSQL data Portability decreases if KenyaBank depends on Aurora-specific capabilities such as: Aurora Global Database Aurora Serverless scaling behaviour Cluster endpoints Aurora-specific replicas Backtrack or other engine-specific functions AWS-specific monitoring and failover automation If the database schema, SQL and drivers remain PostgreSQL-standard, the exit path is still considerably easier than leaving a proprietary database model. Estimated portability: 4 out of 5. Overall portability score: 3 out of 5 KenyaBank’s proposed architecture receives an overall portability score of: 3/5 — Moderately portable The score is not a simple average of the five dependencies. It considers their architectural importance and the effect of existing mitigation opportunities. The architecture earns a moderate score because: Aurora PostgreSQL provides a PostgreSQL-compatible exit path. Amazon MSK is based on open-source Apache Kafka. SAML and SCIM reduce identity coupling. Containers make the application runtime relatively portable. The Strangler Fig pattern supports incremental change. The score is prevented from reaching 4 or 5 because: Session management depends on DynamoDB’s proprietary data model. Domain events risk becoming coupled to EventBridge. Infrastructure is described using CloudFormation. Branch operations depend heavily on Systems Manager. AWS-specific IAM and automation remain embedded in the operating model. The architecture is therefore portable in principle, but exiting AWS would still require a planned transformation programme rather than a simple redeployment. Recommended portability-improvement plan KenyaBank does not need to avoid managed services. It needs to isolate their use. Introduce application adapters Applications should call internal interfaces rather than AWS SDKs directly. Examples include: SessionRepository EventPublisher SecretProvider ObjectStorageClient IdentityClaimsMapper Each interface can have an AWS implementation today and another implementation in the future. Adopt portable event contracts Core banking events should use: CloudEvents envelopes JSON Schema, Avro or Protobuf contracts Versioned domain-event names Provider-neutral metadata A schema-compatibility policy EventBridge and MSK should transport events without owning their business meaning. Move infrastructure definitions towards Terraform or OpenTofu CloudFormation stacks should be replaced gradually. Production resources should be imported carefully rather than recreated. This change improves infrastructure portability, although the resources defined may still be AWS-specific. Use PostgreSQL-compatible features by default Aurora-specific capabilities should require an architecture decision record explaining: The business benefit The portability impact The alternative considered The exit approach The trigger for reassessment Keep identity outside the cloud provider Active Directory should remain the workforce identity authority. IAM Identity Center should provide AWS access federation rather than become the only identity repository. Keep operational scripts portable Systems Manager runbooks should invoke scripts that can also run through Ansible or another orchestration platform. The bank should avoid encoding every operational procedure entirely inside SSM documents. Test the exit plan A portability strategy is only credible if it is tested. KenyaBank should run an annual portability exercise that: Restores a sample Aurora schema into standard PostgreSQL Consumes an MSK topic using a non-AWS Kafka client Replays EventBridge events into an alternative broker Deploys one Terraform/OpenTofu-managed environment Manages one branch server using an alternative tool Exports a sample DynamoDB table and transforms its data Final assessment KenyaBank should not reject AWS-managed services merely because they introduce lock-in. DynamoDB, EventBridge, IAM Identity Center and Systems Manager can reduce operational effort and improve availability, security and delivery speed. Those benefits may be more valuable than complete portability. The most important finding is that not all lock-in is equally risky. DynamoDB creates the greatest application and data portability concern. CloudFormation and Systems Manager create substantial operational dependence. IAM Identity Center is a more acceptable dependency because it integrates through SAML and SCIM, while Aurora PostgreSQL and Amazon MSK offer stronger portability foundations through PostgreSQL and Apache Kafka compatibility. The recommended decision is therefore to continue with AWS, while introducing architectural boundaries around proprietary services. KenyaBank does not need a platform that can move to another cloud overnight. It needs a platform whose dependencies are visible, whose business benefits are understood and whose exit paths remain technically achievable. That is the difference between unmanaged vendor lock-in and a deliberate cloud strategy.

I keep seeing engineers falling into an AI architecture trap. Some engineers try to solve every problem by prompting to a LLM. Others talk about creating an agent for every usecase. So knowing how to use AI has become a core competency. Otherwise you will waste time, money and DevOps resources. If you want to solve an actual business problem without creating an infrastructure nightmare, 99% of your use cases fall into one of these 5 application architectures. Here is how to know which one to use. 1. Basic Prompting (Stateless API) The Use Case: You need to summarize text, extract sentiment, or reformat data (like turning unstructured text into JSON). The data easily fits into the context window. The Trap: Thinking you need a custom model just because the base model didn't output your exact format on the first try. Before you do anything complex, try giving the model 3 concrete examples in the prompt (few-shot prompting). That solves the problem most of the time. 2. RAG (Retrieval-Augmented Generation) The Use Case: You need the LLM to answer questions about your proprietary data (internal wikis, codebase, customer records). You query a VectorDB for the relevant context, shove that context into the prompt, and let the LLM read it. The Trap: Trying to fine-tune a model on your company wiki. Models hallucinate facts. If you need accurate, source-traceable answers based on your internal data, you need RAG, not a fine-tuned model. 3. Chaining / Workflows The Use Case: The task is too complex for one prompt and requires distinct, predictable steps. For example: Step 1 extracts raw text -> Step 2 categorizes it -> Step 3 writes a summary based on the category. The Trap: Cramming a massive, 15-part instruction into a single mega-prompt and crossing your fingers. Break it down into a predictable pipeline. It’s much easier to debug a chain of small LLM calls than one giant, confused prompt. 4. Routing The Use Case: You are dealing with high volume and need to control costs and latency. You build a router that sends simple tasks (like spelling correction) to a fast, cheap model (like Claude Haiku or GPT-4o-mini), and complex reasoning tasks to the expensive, heavy models. The Trap: Sending every single trivial API request to the most expensive flagship model available and bankrupting your cloud account. 5. Autonomous Agents The Use Case: Open-ended tasks where the exact steps aren't known in advance. The LLM is given a goal and external tools (Python interpreter, web search, internal APIs) and loops continuously, evaluating its own output until it achieves the goal. The Trap: Using agents for deterministic workflows. If you can solve a problem with a standard if/then Python script or an Ansible playbook, do it. Do not introduce probabilistic, infinite-looping agents into a workflow that just needs a standard script. The Takeaway: Don't jump straight to training models. Work your way up this list. Start with prompting. If it lacks context, use RAG. If it lacks reliability, chain it. If it lacks cost-efficiency, route it. Only use agents when absolutely necessary. Curious if anyone else has horror stories of teams trying to fine-tune models to learn internal docs? submitted by /u/SeaworthinessHour233 to r/devops [link] [comments]

Claude Code, Gemini, Cloud Run This is a warning post. If you are about to build something on Google — Cloud, Gemini, any of it — read this first and then decide. I picked Google Cloud for my AI project because it looked like the serious choice. Gemini, Vertex AI, Cloud Run, all in one place. Solo dev, portrait retouching service, my own money, my own card, my own quota. Step one of the famous convenience: learning that everything in GCP is denied by default until you find the one permission buried nine menus deep among a million parameters with nearly identical names, and switch it on. Then the next one. Then the next one. Fine — that's the tax for a serious platform. I paid it. I ended up with nine Cloud Run services in asia-south1 and a pipeline I'm genuinely proud of. Then I went to work from the Himalayas, because I think better there. I was doing prompt research — controlled batches of 20-30 generations, reviewed by hand between batches, through Codex, Claude Code and Google's own Antigravity. Precisely the workflow Google advertises on stage. Google's security system looked at all of that and decided, without asking me, that it knew how to protect MY account better than I do. The one I pay for, with my own money. Banned. No reason. No warning. No policy cited. No email. Nothing. Convenience highlight #1: the services kept running. I checked — orchestrator returns 200, all eight processors return 405 to a GET, which is correct because they only accept POST. A stopped or deleted Cloud Run service returns 404. So they are alive, serving traffic, and billing me. Google did not decide my workload was dangerous. It decided it didn't want me near it. The robots stayed. The human was removed. Very cyberpunk. Convenience highlight #2: I was the sole Owner, and GCP never once suggested I add a backup. So there is now nobody on Earth who can administer this project, including Google's paying customer. Can't deploy, can't read logs, can't even shut it down to stop the charges. Convenience highlight #3: I sign in to Claude with that Google account. About SGD 150 a month. Also gone, also still charging. Anthropic can't help me either, because their recovery flow emails a code to the inbox Google just made unreadable. Google's security has now successfully protected me from a company that isn't Google, using money that isn't Google's. Now the part that made me write this. Two days ago Google emailed me: "Appeal approved." They reviewed it, they agreed, the account is restored, please sign in as soon as possible. I have not managed to sign in once since. "Too many failed attempts. You can continue in a few hours." Come back in a few hours. Prove you're not a robot. Prove it again. And again. A new obstacle every time, never a step forward, never one word about what I am supposed to do differently. I am not failing a security check — I cannot get far enough to take one. So I am solving captchas to prove I am human, for a system that flagged me for looking too automated, to reach an account that has officially already been given back to me. My appeal succeeded and nothing changed. An approved appeal that doesn't restore access isn't a resolution — it is written confirmation that they were wrong, followed by absolutely nothing. And here is the actual warning, which is bigger than my situation. Google has built the most user-hostile security system I have ever encountered, and I want to be precise about why, because "their security is annoying" doesn't capture it. Every security system trades off keeping the wrong people out against letting the right person in. Google has resolved that trade-off, permanently and in every product I have touched, in favour of assuming the account holder is the threat. It does not ask you. It does not warn you. It does not tell you afterwards. It decides — and then it makes you prove, over and over, to an automated gate with no human behind it, that you are the person whose name is on the card that pays for it. The part that should actually worry you: this is not the free consumer tier. This is the paid, professional, run-your-business-on-it tier. The same paternalism that locks somebody out of their family photos is sitting in front of production infrastructure with a credit card attached to it, and it is just as willing to fire. It knows better than you. It always knows better than you. In a photo app that's irritating. In front of your company's infrastructure it is a business risk that nobody puts on the pricing page. And because Google made one account the key to everything — mail, Cloud, identity for third-party services — one automated misfire doesn't take one thing from you. It takes the infrastructure, the mailbox, the ability to receive the recovery codes for everything else, and your access to services you buy from other companies. There is no blast door anywhere in that design. One decision, made by nobody, removes all of it at once. For the record, their own Terms of Service section 4.1 says that if Google believes you violated the AUP, Google will notify you and give you 24 hours to correct it before suspending. I received zero notifications and zero hours. Section 4.2 permits instant suspension to "protect the Services" — and the Services, as established above, are magnificently unprotected and still running. What I would actually tell you to do: If you're on GCP as a solo dev, add a second Owner account to every project. Today. I can't anymore, and that is the whole lesson. Don't let one Google account be your identity for anything you can't afford to lose. Use a real email you control for third-party sign-ins. Keep your infrastructure somewhere you can still reach when Google decides, without telling you, that you are suspicious. So here is where this has actually left me. Instead of moving my product forward — the thing I was doing, with my own money, on their platform, in the weeks I had set aside for it — I spend my days solving Google's captchas and writing Google letters. Not to build anything. Not even to get back into Google's own product. To regain access to a service that is not Google's, that I pay a different company for, and that Google is still, right now, blocking me from reaching. That is what their security achieved. Not one bad actor stopped. One paying developer taken off his own work for days, doing unpaid administrative labour to undo an error nobody will explain, while the meter runs. I am not saying the products are bad. Gemini is very good, and I built here on purpose. I am saying that the company running them will take them away from you without a word, hand you an appeal form, approve the appeal, and still leave you outside the door — and that you should price that in before you build a business on it. Extremely convenient platform. Would get banned again. ^(This was written with the help of an AI so I don't shock anyone with my natural vocabulary. Peace and love to everybody — including, reluctantly, Google.) submitted by /u/Key_Lengthiness1518 to r/googlecloud [link] [comments]